2,000 Greater & Lesser Mysteries/2,000 Greater and Lesser Mysteries.iso/computer/virus/mys00507.txt

Text File | 1994-06-10 | 218.5 KB | 4,646 lines

=========================================================================
Date:         Fri, 1 Jul 88 13:08:00 ECT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Ole-Hjalmar Kristensen [phone] <KRISTENS@NORUNIT>
Subject:      Re: OS/2 and virii

Adam Lewis writes : "Once someone has managed to get superuser priv. then
the writing of a virus is within the realm of possibility."

It is NOT necessary to have any special privileges under UNIX to make
a virus, on the contrary, making a virus is probably one of the
"better" methods to attack the security of a UNIX system.

Virii can be created by anyone who has access to the compiler and linker
and some knowledge of the format of an executable file.
Once the virus is created, it can be inserted into a copy of a system
program, for example ls. This infected ls can then be spread to all
directories where the creator has write access, and the first time a
user tries to list the files, it will infect any other executables owned by
this user.

I have tried this myself, using a harmless virus which is intentionally
built so that it needs a specific file to propagate itself. The UNIX system
on which the test was performed is isolated from our other machines in order to
avoid uncontrolled infection. Furthermore, the virus maintains a log which
shows all executables infected.
This virus has successfully infected programs such as ps, ls, sh as well as
other executables

I will not go into any details about how the virus works, but it was created
in approximately two days of work. One day to dig up the necessary information,
and another to implement and test it.

I have drawn the following conclusions from this experiment :

* Creating a UNIX virus is simple.

* The infection can spread from user to user.

* As soon as the superuser runs an infected program, the virus can get
  superuser privileges.

Ole Kristensen

=========================================================================
Date:         Fri, 1 Jul 88 22:09:17 PLT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Andrew Vaught <29284843@WSUVM1>
Subject:      UK Virus

Crossposted from RISKS digest:

-------------------------------------------------------

========================================================================

Date:     Fri, 1 Jul 88 10:36:42 CDT
From: Will Martin -- AMXAL-RI <[e-mail]>
Subject:  New UK Virus

The following is a complete item from the FEDERAL BYTES column (p. 42) of the
June 27, 1988, issue of Federal Computer Week, which just arrived in today's
mail (July 1):

Oh, No - Not Maggy!

Sources of reasonable reliability within the British Ministry of Defense (MoD)
report that a computer virus has broken out. It seems that MoD uses a number
of Macs, largely for graphics but some of them for word processing.

Whenever anyone writes "Margaret Thatcher" or "prime minister", the screen
[image] vanishes, along with whatever was on it. In the place of the missing
document appears a picture of Maggy, with a Union Jack behind her.

MoD, say our sources, has not found a cure.

---------------------------------------------------------

Does anyone know anything else about this? If true, this is probably an
example of someone infecting a computer `manually' and leaving it sit for
someone else to trigger. Digitized pictures on the mac can take up quite a
bit of space (20-30k?) on a disk, that would probably be easy to notice.
  Then again, on macs, the only place it tells you how big your file is is
when you ask for a `by-name' description, and even then sizes are only given
in kilobytes.


         Andy
=========================================================================
Date:         Fri, 1 Jul 88 18:04:14 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Joe Sieczkowski <[e-mail]>
Subject:      Questionable Ads



Over the course of the last 6 months, I've seen numerous
questionable ads concerning virus protection software.
However, the one SysteMate Incorporated placed in the June
6'88 Info-World on page 58 takes the cake.  The ad starts
with the caption "You had better STOP VD, before it stops
you", and follows with the typical scare-tactic approach.

In the ad, SysteMate states that SecurMate is "the only
software package that GUARANTEES you protection against
all strains of VD."  Furthermore, it seemingly (<- note
this word) challenges anyone who breaks the program a 60%
controlling interest in the company.  If that's not
incentive, what is?  I can picture everybody and his
brother trying to develop viruses to do this.  Personally,
I lock horns with enough viruses, I don't need more.

I took the liberty of calling the company.  I know there
is no 100% effective "software" method of protecting a PC
(an unsecure system where real memory and the i/o ports
can be directly addressed).  During my conversation with
one of the technical people (an ex-NSA person no less), I
questioned the method of protection.  Although quite
sophisticated, I proposed a viral method which could
probably circumvent the protection.  (I rather not go into
the specific method here.)  However, this method implied
that I put a PD piece of software on the system containing
the virus.  The answer I received was something like "How
can you expect your system to be secure if you subject it
to untrusted software."  To which I replied, "If all my
software was trusted, I wouldn't need your package."  At
this point I inquired about there offer.  Apparently their
offer of "breaking there system" implies being able to
read a message that they ran through their one-way
encryption scheme.

The end of the article stated "our highly satistfied
customer base, each with hundreds or thousands of copies
installed, include the Austrailian Postal Department,
Chase Manhatten, Citibank, Donaldson, Dupont, EXXON,
General Motors, Generall Electric, Honeywell, IBM, Mobil,
NSA and other government entitlies, Nynex, Pacific
Telesis, Prudential, Rockwell International and many
others."  I didn't check this out, but I find it hard to
beleive.  (If your from one of these organisations, please
comment.) Perhaps all of these agenties bought an evaluation
copy.

Misleading advertising on this area has run rampant.

=========================================================================
Date:         Fri, 1 Jul 88 11:42:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         [e-mail]
Subject:      Re: Some BYTES from fidonet (sorry)
In-Reply-To:  Message of 30 Jun 88 18:00 EDT from "Len Levine"


Hurrah for Lee Kemp!  That is an incredibly valuable piece of work.  I
wish that I had said it.  While the INTERNET is not quite as open as
FIDONET, there are numerous gates and lots of traffic between them.
Therefore, whatever applies to them applies equally to us.  As I
reported earlier, work is going forward.

William Hugh Murray, Fellow, Information System Security, Ernst & Whinney
2000 National City Center Cleveland, Ohio 44114
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840
=========================================================================
Date:         Fri, 1 Jul 88 11:09:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         [e-mail]
Subject:      Re: do you believe in magic?
In-Reply-To:  Message of 30 Jun 88 18:48 EDT from "me! Jefferson Ogata"


>God forbid that anyone should actually write an operating system or
>compiler.  Just think of the damage that would cause to everyone's
>data.  It's THIS kind of unjustified fear (superstition) that prevents
>progress along so many different paths.  A virus is a PROGRAM.  That
>program has certain characteristics that one can use to one's advan-
>tage.  It seems to me that a number of people out there are terrified
>by one word: 'virus'.  This fear of viruses prevents them from even
>considering the possibilities for code using viruses.

It is not the wand that we fear.  It is not even the magician.  It is
the apprentice.  We are particularly afraid of the apprentice who thinks
that he knows what the magician does not even pretend to know.

>The simple truth is that viruses ARE controlled entities.  They do what
>they are supposed to do when they are properly written.  The COMMAND.COM
>virus, for example, infects COMMAND.COM.  It performs a deterministic
>action on COMMAND.COM, then trashes the disk.  It doesn't infect other
>environments, only those running under DOS with COMMAND.COM.  It would
>be difficult, in fact, to write viruses with potential for infecting
>multiple environments.

For example, the above suggests to me that the author does not
understand the difference between the execution environment and the
system population of which it is a part.  The creators of the Pakistani
virus could predict exactly how it would behave in a PC; they had no
idea how it would behave in the world.  The creator of the XMASCARD knew
how it would behave in a CMS environment.  He might make some
intelligent predictions about how it would behave in BITNET.  He could
not possibly have known how it would behave in VNET even if he could
have predicted that it might end up there.   It is not the potential for
infecting multiple unlike environments that concerns me.  It is the
ability to know the extent of the intended environment.

>It would
>be difficult, in fact, to write viruses with potential for infecting
>multiple environments.

True.  A virus is target specific.  For example:

>If we're following the analogy of biological
>viruses, consider how they work, which is quite similar to computer
>viruses.  A biological virus consists of a head and some legs.  The virus
>has a key which matches a particular site on a cell, called the active
>site.  Viruses can only infect those cells that have an active site on
>them corresponding to the virus key.  This site is the location where
>the virus DNA material is injected.  Because of this, biological viruses
>are well-suited to the fighting of cancer.  If a virus can be tailored
>to find an active site that exists only on cancer cells, it will
>destroy
>cancer cells throughout the body.  When there are no more cancer cells,
>the virus will die.  If biological computers can be added to these
>viruses, they can be programmed to die after n generations, thus
>preventing the possibility of spread to other animals whose cells might
>carry the same active site.

Which, of course, admits of the very danger that concerns us.  That is,
that there is something in the environment, unknown to the creator of
the virus, that is vulnerable to it.

Cancer has demonstrated itself to be highly resistant to many
strategies.  We might be justified in taking some risk to deal with it.
Almost any problem that will yield to a program virus, also yields to
other programs without the uncertainties of a virus.

Of course, Mr. Ogata does not admit to much uncertainty.  And, I am
sure, that he can hypothesize some problem that will justify continued
experimentation on which so many seem bent.  One can only argue for the
truth that he sees.

William Hugh Murray, Fellow, Information System Security, Ernst & Whinney
2000 National City Center Cleveland, Ohio 44114
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840
=========================================================================
Date:         Fri, 1 Jul 88 10:57:51 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "David M. Chess" <CHESS@YKTVMV>
Subject:      Forwarding a colleague's reply

A colleague had the attached reaction to the signature-authentication
idea that the FidoNet article suggests.   (My own reaction is that
Kemp dismisses the possibility of CRC-type protection way too lightly;
"can be easily bypassed", indeed!)   Perhaps someone with the right
access could send it on its way back to Mr. Kemp?

DC

<Forwarded stuff follows>

Re: Lee Kemp's FidoNet article

     As I see it, the purpose of this 'tamper-proof' packaging is to
prevent the program from being infected from the time it leaves the
author or factory until it reaches my hot little hands.

     This has several advantages over the current state of affairs, and
should be encouraged, but also leaves plenty of exposures.

The advantage of the scheme is:

* One can be quite sure that the product has not been tampered with
  since its encryption.  If it comes from a commercial manufacturer,
  listing the public decryption key in the docs, one can be sure that
  one has the right program and that it hasn't been infected since its
  packaging.

Disadvantages/Exposures:

* In the case of shareware, a malicious person could decrypt the
  program, infect it, and then re-encrypt it with a new pair of keys.
  Wily Hacker could then pose as the author on any bulletin board not
  requiring user authentication, and thereby spread the infected
  version.  Soon there are two or more versions of the program (with
  different keys) floating about, and people will not know which one is
  the clean one.  Considerable FUD.  Some will be infected before
  discovering that there is a danger, as the result of a false sense of
  security brought on by the nature of the packaging.

* If the developer's machine is infected, then there is a very good
  chance that the new program will be infected.  This scheme would not
  have prevented the Aldus Freehand/MacMag incident.

* Boot block and operating system viruses will continue as usual.

* If your machine is already sick, this does not prevent it from
  infecting the executable once you have removed the protective
  packaging.

* An infected encryption/decryption program could do all sorts of nasty
  things.


Dan Hankins
=========================================================================
Date:         Tue, 5 Jul 88 09:10:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Shawn V. Hernan" <VALENTIN@PITTVMS>
Subject:      stupid question

Can someone please tell me what CRC protection is? I don't know much
about this sort of thing, and I just want to learn.



                                                Shawn Hernan
                                                University of Pittsburgh


please mail ( don't post) to [e-mail]
=========================================================================
Date:         Tue, 5 Jul 88 09:35:22 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject:      Over the weekend problems with LISTSERV


Dear readers:

Over the long (Fourth of July) weekend, our LISTSERV ran out of disk
space for the VIRUS-L archive files, and subsequently stopped sending
out any submissions.  The problem has been fixed, but some submissions
were held over the weekend, and some users may have had difficulties
accessing the archive files.  I do not believe that any submissions
were lost, however.  Once the LISTSERV was re-started this morning,
all of the held submissions were then sent out to the list.

I apologize for any inconveniences that this may have caused.

Ken

Kenneth R. van Wyk                    Hobbes: Wow, buried treasure right
User Services Senior Consultant               where you said it'd be!  A
Lehigh University Computing Center            wallet full of money!
Internet: <[e-mail]>  Calvin: Yeah, it's Dad's.  I buried it
BITNET:   <LUKEN@LEHIIBM1>                    here last week!
=========================================================================
Date:         Tue, 5 Jul 88 09:52:46 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject:      forwarded comments on OS/2 from David M. Chess


Date: 1 July 1988, 09:38:00 EDT
From: David M. Chess                                 CHESS    at YKTVMV
To:   VIRUS-L at LEHIIBM1
Subject: OS/2 and viruses


I'd like to correct a little more misinformation, about OS/2 this
time.   Note that all this is just my understanding of the case,
and in no sense Official Word from my employer (on the other hand,
I'm pretty sure that I'm right!).

It's very simple (just a line in CONFIG.SYS) to bring up OS/2 in
a mode where there is no DOS box.   DOS-only programs (including
DOS-only viruses) will not run on a machine configured that way.
So if you consider the DOS mode a risk, you can easily turn it off.

On the other hand
> the hardware memory management of the new processors will
> defeat any attempt at cross-process infection by viruses of
> the (in DOS terms) .COM/.EXE-hidden kind
is not quite true, I don't think.   COM/EXE viruses typically
spread by altering other executables as they exist as files
on disks.   "hardware memory management" isn't relevant to this
kind of infection (it protects memory, not disk images).  Even
the typcial disk-image protection only protects one's executable
files against writes by *unauthorized* users and processes, but
these viruses tend to spread Just Fine by way of *authorized*
users and processes.  (That is, if George is authorized to write
to 25 executable files, and George gets an infected program and
runs it, those 25 executables are going to get infected (and so
are the executables of anyone else who runs them) no matter *how*
"unbreakable" the disk protection is in the usual sense.)

* Most traditional "security" and "protection" schemes provide
  little hindrance to viruses.

DC

Kenneth R. van Wyk                    Hobbes: Wow, buried treasure right
User Services Senior Consultant               where you said it'd be!  A
Lehigh University Computing Center            wallet full of money!
Internet: <[e-mail]>  Calvin: Yeah, it's Dad's.  I buried it
BITNET:   <LUKEN@LEHIIBM1>                    here last week!
=========================================================================
Date:         Tue, 5 Jul 88 14:20:48 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         me! Jefferson Ogata <OGATA@UMDD>
Subject:      Bill Murray's fears

You don't fear the wand; just the apprentice?  What makes you think the
apprentice isn't already out there?  What I propose is intelligent use
of viruses by professionals.  The apprentice is irrelevant.  The appren-
tice will go about his business whether others write useful viruses or
not.  And your whole viewpoint indicates a vast misconception of the
relationship of viruses to other useful programming tools.

Consider the biological viewpoint once again: we use only existing
animals and plants as resources.  We do not design them.  This is where
the biological analogy becomes useless.  You seem to be arguing that it
is dangerous to utilize gene-altered viruses for biological purposes.
What about gene-altered cows?  Aren't they just as dangerous in that
they might have unpredictable effects through hormonal secretions in
milk?  Any gene-altering introduces new possibilities into an environ-
ment.  But programs are ALL gene-altered.  We're not discussing a brand
new area of exploration such as gene-altering.  We're merely discussing
the use of one particular type of gene-altering.  All programs are the
result of human intervention.  Why is it that we don't have accidental
Trojans running rampant?  It's because people write programs according
to general guidelines such as "use files to store data".  Programs that
use whole disk tracks to store data regardless of the file system would
do heavy damage to peoples' data.

What I've been working up to is this: people need a set of guidelines
they can use in the writing of beneficial viruses.  Perhaps operating
system support could even be used.  Virus managers and whatnot.  It is
obvious that without any knowledge of infection-modes and environments,
idiots will write stupid viruses.  But I believe viruses should be
regarded in the same way as "normal" programs.  There are correct ways
(apart from style) to write all programs; why not viruses?  And don't
come back with remarks about hubris, how I don't know anything, and
why people won't follow guidelines.  There ARE malicious people out
there.  They aren't writing beneficial viruses, and they don't care
about beneficial viruses.  The worst thing beneficial viruses could do
is provide a vehicle for transport of malicious viruses.  As if there
aren't already enough vehicles.  As to the question of unpredictable
virus spreading, if the necessary virus protection methods ever get
developed and installed, it won't be possible for ANY virus to spread
uncontrollably.  In the meantime, viruses are already strictly limited
in their environments; as I said before, it's HARD to write viruses
that can live in multiple environments.  Computer environments are
nothing like biological environments, where biological hardware has
common elements between organisms.  Even if two computers have the
same processor, it will be difficult to get a virus to spread between
them if they use different operating systems.  And appropriate guide-
lines might precisely limit environments.

By the way, things like CHRISTMA EXEC require gross stupidity and care-
lessness on the part of the target user.  I don't think this case is a
good model for any conclusions.  The spread of this virus was the fault
of the users as much as the writer, if not more.  And this program is
also a network virus, not a program-infecting virus, so once again it's
a poor model.

- Jeff
=========================================================================
Date:         Tue, 5 Jul 88 16:08:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Woody <WWEAVER@DREW>
Subject:      intro to CRC in 1,000 words...

"Shawn V. Hernan" <VALENTIN@PITTVMS> writes,

>Can someone please tell me what CRC protection is? I don't know much
>about this sort of thing, and I just want to learn.

  I think its appropriate to post a quickie overview of what CRC, or Cyclic
Redundancy Check, protection can do for you.  In essence, what one is
trying to do is write down a number associated with your data that will
help you know whether or not the data has been altered.  Originally, it was
intended as a means of telling whether or not a message was transfered
correctly: if the CRC of the transmitted message wasn't a pre-agreed upon
value, the sender knew to try again.  So keep in mind that what it was
designed for is to detect "random" errors in transmission.

  The simplest example of a CRC is what is called "even" parity.  What the
sender does is express his message in binary, count the number of 1's, and
append a 1 or a 0 to his message depending upon if that number is odd or
even.  The reciever then looks at what he's recorded, and if the total
number of 1's in the message is even, he is happy - throws away the last
bit (the parity check bit) to recieve the message.  If the total number of
1's is odd, then he asks the sender to retransmit.

  The problem with something this simple is that while it will tell you
something is wrong if exactly one bit was garbled, it won't tell you if
something is wrong if exactly two bits were garbled.  (It detects the error
only if an odd number of errors were made.)

  There is a natural way to improve this - instead of working with just
[number of 0's and 1's mod 2] use something a bit more detailed.  Suppose
you are working with (base 10) numbers, and are trying to send a message to
a friend.  What you agree to do is send the number, and then send a single
digit that is the sum of the digits, then summed as many times as needed to
get a single digit.  For example, suppose you wanted to send the number
2,147,483,648.  Since 2+1+4+7+4+8+3+6+4+8 = 47 => 4+7 = 11 => 1+1 = 2, so
you would send 21474836482.  Your friend would strip off the last digit
(2), and then add up the digits to make sure they added up to two.  If he
dropped a digit, it would be detected.  If he changed a 2 to a 3, a 4 to
and 8, and a 1 to a 9, it would be detected, etc.

  Mathematically, what you are doing is sending the remainder after
dividing the original number by nine.  (Nine is convienent because it is
one less than the base.)  The basic idea of CRC is to consider the message
(or datafile) as one gigantic binary number, compute the remainder after
dividing by a large binary number, tack that onto the end of the message,
and send it.  Choice of the "large binary number" is made upon certain
grounds of primality or other properties: since you are mapping a larger
set (all messages) into a smaller set (the residues) you want to ensure
that all the residues are covered, they are all hit about equally often, no
two messages are too "close", etc.  If the adversary is random - i.e. a
noisy telephone line or the like - and so changes are made to bits at
random, then mathematically one can show this is an excellent form of
protection.

  However, the malefic forces we are trying to protect against are not
random.  For example, suppose our virus is trying to scramble our data
file, and knows we are going to use a parity check.  As long as the virus
is careful enough to always make EXACTLY an even number of changes, the CRC
won't detect it.  Similarly, if the virus changes our base ten number by a
multiple of nine, we won't detect it.  But if it changes our base ten
number by something that ISN'T a multiple of nine, we WILL detect it.

  This is where the discussion of the "random CRC polynomial" comes in. The
idea is that even if you restrict yourself to, say, a 16-bit check tacked
on the end (where the odd-even scheme is just a 1 bit check) you have a
great deal of leeway.  You need to divide by a 16 or 17 bit number (so you
have a 16 bit residue) and you want to use a prime number (for mathematical
reasons) but you don't have to use a specific one.  The virus can protect
itself from detection by a single residue check, but it is very hard to
protect from ALL the residue checks.  For example, suppose we are going to
do at most a 4 bit residue.  We might record our message plus the remainder
after dividing by 2, 3, 5, 7, 11, or 13.  The virus changes message to
message*.  If we used all of the checks, then the residue of message* under
2, 3, 5, 7, 11, and 13 would have to be the same as under message - and to
accomplish that, message* would have to be the same as message, up to
2*3*5*7*11*13 = 30,030. For four bit protection, we're able to assure
integrity up to a fairly large degree of accuracy.  (In particular, if we
never sent more than 14 bit messages, we could be sure it was right!)  Of
course, we probably aren't going to use every one of those, but if we just
picked one or two, and someone else chose a different one or two, etc,
someone will detect the garbling.

  The mechanical details of CRC are rather interesting, and the
mathematical details are quite beautiful (sitting squarely in number theory
and field theory).  Almost any upper division textbook on the general
subject should have some information about it.  It is quite accessible, and
I'd recommend it to anyone curious about the subject.

woody
[e-mail]
=========================================================================
Date:         Tue, 5 Jul 88 17:40:56 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Otto Stolz [phone] <RZOTTO@DKNKURZ1>
Subject:      Receiving multiple files under VM/SP 5

Hello folks,

as we had discussed in VIRUS-L back in June, a file could inadvertently
be RECEIVEd under CMS Release 4 (and the earlier releases) -- if this
file was hidden as a second partition in a NETDATA file.  This was
unanimously considered a dangerous feature, as the hidden file could be
some trojan horse, e.g. a PROFILE EXEC which would become active at the
next LOGON.

Meanwhile, I've tested this feature under CMS Release 4 and the official
antidote of CMS Release 5.  Thanks to everybody who helped with sending
double-edged files and/or remarks to me.  This note is meant as a digest
of my findings.


A NETDATA file
==============
containing a note and an attached data file can be sent from a MVS/TSO
installation to a VM/SP installation by one of these commands:
>   TRANSMIT node.user DSN(fn.ft) MESSAGE
>   TRANSMIT node.user DSN(fn.ft) MSGDSNAME(msgfile)
where:
    fn ft      are the two components of the CMS file-id
               (up to 8 characters, each);
    node user  are the two components of a BITNET or EARN address;
    msgfile    is the MVS file-id of the note to be sent.

Under Release 4,
----------------
the VM/SP user sees two files in one message, separated by a double line,
when PEEKing at the NETDATA file before RECEIVing it (as one should
always do :-).  After issuing RECEIVE, he will receive a note AND a file
-- and he will only be informed of the former.  If a NETLOG file is kept,
both the note and the data file will be logged therein, e.g.:
> Note JAMES    NOTE     A0 recv from JAMES    at XXXXXXX  on 06/22/88 10:04:20
> File HELP     EXTRACT  A  recv from JAMES    at XXXXXXX  on 06/22/88 10:04:20
sent as JAMES.TRANSMIT.HELP.EXTRACT

For long files, which cannot be PEEKed in their entirety, this feature
indeed constitutes a severe safety threat.

The SENDFILE, NOTE, and RECEIVE commands use a module DMSDDL for sending/
receiving NETDATA format files.  DMSDDL is documented in DMSDDL ASSEMBLE.
I suppose, there's a modified DMSDDL MODULE available for node admini-
strators from their nearest backbone LISTSERV, that will avoid receiving
hidden files, in Release 4.

With Release 5,
---------------
the RECEIVE command has been enhanced with a new triple of options:
FULLPROMPT, MINPROMPT, and NOPROMPT.  With FULLPROMPT, or MINPROMPT
(default), RECEIVE will no longer write a file to the user's disk with-
out his consent.

As there have been added *new options* to the command syntax, I had
expected to read about this enhancement in the "Release 5 Guide", or in
"Using Release 5 Enhancements".  But this change of the command syntax
isn't mentioned there at all (perhaps a mere oversight -- or perhaps
an inter-release enhancement not considered worth to be repeated in
these manuals);  on the other hand, some trifling details (e.g. look up
RECEIVE in the index) are covered.  I regret my rash, inappropriate
remark of 21 June on this account.

The new prompt allows the user to receive every partition of a NETDATA
file under the name given, or under a new name chosen by the user, or to
deny receiving it.  If any partition of a file is not received, then the
whole partitioned file remains in the user's reader.  BTW, as any new
prompt, also this one constitutes an incompatibility between Release 4
and Release 5: a disconnected machine running into an unforeseen prompt
will stall (and will be forced after 15 minutes)!

Furthermore, the PEEK command displays two message lines, containing
the note's and the appended file's file-ids.

I'll keep a file with a Release 5 sample dialogue for another fortnight.
Anybody interested in it please drop me a short note.



CP SPOOL PUN CONT
=================
is another CMS possibility to create multiple files in another person's
reader, as mentioned before in VIRUS-L.  Under Release 5, these files
can be overcome:  they can be RECEIVED into one single, harmless disk
file.  If they are read in using READCARD, however, they are separated
into several single disk files; this happens under user control if he has
specified the new FULLPROMPT or MINPROMPT options.

As opposed to RECEIVE, READCARD defaults to the NOPROMPT option.  Hence,
if you want to be on the save side, be sure to use READCARD always with
the MINPROMPT or FULLPROMPT option!  Regrettably, the CMS DEFAULTS com-
mand does *not* apply to the READCARD command.

That's all for now.  Best regards
                                   Otto
=========================================================================
Date:         Wed, 6 Jul 88 07:59:23 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject:      forwarded info on NASA virus from Keith Peterson


From: Keith Petersen <[e-mail]>
Subject: FBI to investigate rogue computer program at NASA

FBI TO INVESTIGATE ROGUE COMPUTER PROGRAM AT NASA

NEW YORK (JULY 4) UPI - NASA officials have called on the FBI to
investigate a rogue computer program that has destroyed information
stored on its personal computers and those of several other government
agencies, The New York Times reported today.

The program was designed to sabotage computer programs at Electronic
Data Systems of Dallas, the Times said. It did little damage to the
Texas company, but wreaked havoc on thousands of personal computers
nationwide, company spokesman Bill Wright told the newspaper.

Although damage to government data was limited, NASA officials have
asked the FBI to enter the case since files were destroyed, projects
delayed and hundreds of hours spent tracking the electronic culprit at
NASA and at the Environmental Protection Agency, the National Oceanic
and Atmospheric Administration and the United States Sentencing
Commission.

It was not known how the program, which damaged files during a
five-month period beginning in January, spread from the Texas company
to networks of personal computers and whether it was deliberately
introduced at government agencies or brought in accidentally, the
Times said.

The computer program is one of at least 40, termed ''viruses,'' now
identified in the United States, computer experts said. Viruses are
designed to conceal their presence on a disk and to replicate
themselves repeatedly onto other disks and into the memory banks of
computers. The program currently being investigated is called the
scores virus, the newspaper said.

Some government officials say viruses are spread through informal
networks of government computer users who exchange publicly available
software. Viruses often lie dormant and then explode on a certain day
or on contact with a specific computer program. They can erase entire
disks, such as happened with a one word virus that flashed the word
''Gotcha!''

Kenneth R. van Wyk                    Hobbes: Wow, buried treasure right
User Services Senior Consultant               where you said it'd be!  A
Lehigh University Computing Center            wallet full of money!
Internet: <[e-mail]>  Calvin: Yeah, it's Dad's.  I buried it
BITNET:   <LUKEN@LEHIIBM1>                    here last week!
=========================================================================
Date:         Wed, 6 Jul 88 09:43:08 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Joe McMahon <XRJDM@SCFVM>
Subject:      Scores Arrest

A quote from the Washington Apple PI Journal this month:

"Donald Burleson of Fort Worth, TX has been arrested on felony charges as
the creator of the Scores virus.  If convicted of 'harmful access to a
computer' he faces up to 10 years in jail.  He is accused of executing
programs 'designed to interfere with the normal use of the computer' and
of acts 'that resulted in records being deleted.'"

Those sure are wide-open categories as crimes, aren't they?

--- Joe M.
=========================================================================
Date:         Wed, 6 Jul 88 11:36:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Jim Shaffer, Jr." <SHAFFERJ@BKNLVMS>
Subject:      RE: Scores Arrest

>A quote from the Washington Apple PI Journal this month:

>"Donald Burleson of Fort Worth, TX has been arrested on felony charges as
>the creator of the Scores virus.  If convicted of 'harmful access to a
>computer' he faces up to 10 years in jail.  He is accused of executing
>programs 'designed to interfere with the normal use of the computer' and
>of acts 'that resulted in records being deleted.'"

>Those sure are wide-open categories as crimes, aren't they?

Wide-open? You bet. Everybody at this site has been guilty of "(interfering)
with the normal use of the computer" at one time or another :-)

Nevertheless, you can't believe how happy I am that someone's gotten nailed
for writing a virus. The only problem is, how is anyone sure that it's him?
Anybody have any further info?

_______________________________________________________________________________
|  James M. Shaffer, Jr.   | Bitnet: shafferj@bknlvms                         |
|  P.O. Box C-2658         | Internet: [e-mail]|
|  Bucknell University     | UUCP: ...!psuvax1!bknlvms.bitnet!shafferj        |
|  Lewisburg, PA USA 17837 | CSNet: [e-mail]      |
-------------------------------------------------------------------------------
| "He's old enough to know what's right and young enough not to choose it;    |
|  He's noble enough to win the world but fool enough to lose it."            |
|                                   -- Rush, "New World Man", on _Signals_    |
-------------------------------------------------------------------------------


=========================================================================
Date:         Wed, 6 Jul 88 16:01:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         [e-mail]
Subject:      Re: Scores Arrest
In-Reply-To:  Message of 6 Jul 88 09:43 EDT from "Joe McMahon"


>Those sure are wide-open categories as crimes, aren't they?

I think they call that "frontier justice."  I understand that you can
still be hung there for rustling cattle (but not for shooting your wife).

Yes, they are wide open categories.  However, there must be very narrow
specifications.  It will be interesting to read them.  My recollection
is that SCORES had very specific targetes within EDS.  Not exactly a
"let's turn it loose and see what happens."

Bill
=========================================================================
Date:         Thu, 7 Jul 88 10:32:57 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         [e-mail]
Subject:      Removable hard disks

I just saw in the July issue of BYTE magazine that they now have
removable hard disks, something that has been suggested as being
desireable for viral protection. Thus, you could have two formatted
hard disks, one for using with suspicious code and one for
normal use. Of course, this would not make your system virus proof
if the proper precautions weren't taken, but it is another tool
in the fighting of virii and such.
David Slonosky                            ~ Know thyself?
Queen's University                        ~ If I knew myself,
Kingston, Ontario                         ~ I'd run away.
=========================================================================
Date:         Thu, 7 Jul 88 10:39:04 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         [e-mail]
Subject:      VAX/CMS and transportable virii

I routinely use YTERM and a two floppy IBM compatible to transfer data
to and from the mainframe. I know that it has been suggested that a
virus could be written on an AT with the proper code to transfer to
a VAX/CMS environment, but would it be possible to design one that
would be transparent to DOS and still be transmitted upon file transferring?
What about having one tacked on to the end of a program which got activated
somehow? I guess what I'm asking are 1) are security measures strong enough
to prevent a virus from coming "alive' in this fashion and 2) is this
sort of thing possible in the first place? (Actually, these should be
reversed, but I'm only working on my second coffee this morning (8*-).)
David Slonosky                            ~ Know thyself?
Queen's University                        ~ If I knew myself,
Kingston, Ontario                         ~ I'd run away.=========================================================================
Date:         Fri, 8 Jul 88 11:37:51 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Joe McMahon <XRJDM@SCFVM>
Subject:      Scores Arrest - Hold It!

          *** ATTENTION ALL READERS! MUCHO IMPORTANTE! ***

After some phone calls here and there, and some background checking by
Mark Trumbull of the Christian Science Monitor, we have found that, yes,
Mr. Burleson was arrested on charges of computer sabotage and burglary.
He was NOT, however, the perpetrator of the Scores virus. A Wall Street
Journal article (page 1, Friday, June 17), detailed that he was accused
of the above in connection with a company called USPA&IRA. Not EDS, not
Scores, something else entirely.

See what I get for jumping off a cliff with a single source? PLEASE tell
everyone you have told that the arrest was, alas, a rumor.  It's probably
spread faster than the virus itself!

--- Joe M.
=========================================================================
Date:         Mon, 11 Jul 88 09:49:04 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject:      Question about virus simulator



As mentioned here some time back, the National Bulletin Board Society
has a product called a virus simulator.  They also, by the way, market
an anti-virus program, but its name escapes me at the moment.  Does
anyone have any experience with their virus simulator that you could relate
to VIRUS-L readers?  It's supposed to test an anti-virus package against
most of the current known virus infiltration methods.  I've heard some
conflicting messages about its usefulness, though.  For example, it is
alleged to come up with erroneous reports against some of the current
crop of anti-virus products by reporting that a particular virus would
be able to infect the system, when the opposite has been proven to be true.
It would be interesting to hear some independent evaluation(s) of this
product.  Any comments on this sort of testing scheme?


Ken

Kenneth R. van Wyk                    Hobbes: Wow, buried treasure right
User Services Senior Consultant               where you said it'd be!  A
Lehigh University Computing Center            wallet full of money!
Internet: <[e-mail]>  Calvin: Yeah, it's Dad's.  I buried it
BITNET:   <LUKEN@LEHIIBM1>                    here last week!
=========================================================================
Date:         Mon, 11 Jul 88 11:34:26 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject:      New version of PKARC on-line


I finally got around to updating the PKARC program that's on-line
here at Lehigh for VIRUS-L readers.  I now have the file PK36 UUE
available on the LISTSERV.  The file was downloaded directly (by me)
from SIMTEL20.ARPA.  Keith Peterson got the version on SIMTEL20.ARPA
directly from Phil Katz's bboard.

As with all of the binaries on the LISTSERV, PK36 is distributed
as a uuencoded file.  See the monthly announcement message for
instructions on how to uudecode this file back into a binary file.


Ken

Kenneth R. van Wyk                    Hobbes: Wow, buried treasure right
User Services Senior Consultant               where you said it'd be!  A
Lehigh University Computing Center            wallet full of money!
Internet: <[e-mail]>  Calvin: Yeah, it's Dad's.  I buried it
BITNET:   <LUKEN@LEHIIBM1>                    here last week!
=========================================================================
Date:         Mon, 11 Jul 88 12:40:53 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Len Levine <[e-mail]>
Subject:      possible virus?


I heard just yesterday that one of my friends was having trouble with
a copy of Norton Utilities version 3.00.  He pointed out that the copy
which he runs from a protected floppy disk works well, but when he
loads that copy onto his hard disk, it fails.  He also noted that the
copy from the protected disk showed differences between itself and the
hard disk copy he had just made.  The problem repeated several times.
No other symptoms.

Any ideas?  I have not tried to copy this material to my machine, I
have not asked about the date signature on the copies, or about the
sizes of the files.

[e-mail]




=========================================================================
Date:         Tue, 12 Jul 88 15:17:51 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject:      forwarded virus seminar announcement



Date: 12 July 1988, 13:10:34 EDT
From: Nick Simicich                                  NJS      at YKTVMH
      8/863-7033 [phone]
      T.J. Watson Research Center
      Yorktown Heights, New York
To:   VIRUS-L  at LEHIIBM1
      SRWHITE  at YKTVMH

The following seminar is open to the public, but attendance space is
limited.  Those of you who are interested in attending should call
Steve R. White at [phone].

Nick Simicich

Subject: Seminar by Fred Cohen


Date  : 20 Jul 1988
Time  : 2:00 - 3:00
Place : IBM Research, Hawthorne NY, Room H1-E53
Host  : Steve R. White  (SRWHITE at YKTVMH)

    Models of Practical Defenses Against Computer Viruses

                         Fred Cohen
                  University of Cincinnati

Computer viruses are pieces of programs that attach themselves to
other executable programs.  When that executable program is run, the
virus searches for yet another executable program and infects it with
the virus.  Besides spreading the infection, a virus can perform
malicious actions like erasing files or randomly changing data.

In this talk, we describe a way to detect computer viruses and
prevent them from spreading before they cause significant damage.
We show how this method can be used to protect information in both
trusted and untrusted computing bases, show the optimality of this
technique, and present the results of experimental trials in two
computing environments.

Kenneth R. van Wyk                    Hobbes: Wow, buried treasure right
User Services Senior Consultant               where you said it'd be!  A
Lehigh University Computing Center            wallet full of money!
Internet: <[e-mail]>  Calvin: Yeah, it's Dad's.  I buried it
BITNET:   <LUKEN@LEHIIBM1>                    here last week!
=========================================================================
Date:         Tue, 12 Jul 88 18:18:35 -0900
Reply-To:     FSFSW@ALASKA
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         FREDERICK S WELDON <FSFSW@ALASKA>

SENDME DIRTY DOZEN
=========================================================================
Date:         Tue, 12 Jul 88 20:48:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Jim Shaffer, Jr." <SHAFFERJ@BKNLVMS>
Subject:      An error in the new NetMonth

Due to an error on the part of Rich Zellich, the Internet maintainer of
the List of Mailing Lists, I am incorrectly listed in the new issue of NetMonth
as the owner of Virus-L.  I notified Rich of his mistake as soon as I received
his update list, several weeks ago, but he apparently couldn't correct it
in time to prevent the error in NetMonth.  I have notified Chris Condon
of the error.

_______________________________________________________________________________
|  James M. Shaffer, Jr.   | Bitnet: shafferj@bknlvms        CIS: 72750,2335  |
|  P.O. Box C-2658         | Internet: [e-mail]|
|  Bucknell University     | UUCP: ...!psuvax1!bknlvms.bitnet!shafferj        |
|  Lewisburg, PA USA 17837 | CSNet: [e-mail]      |
-------------------------------------------------------------------------------
| "He's old enough to know what's right and young enough not to choose it;    |
|  He's noble enough to win the world but fool enough to lose it."            |
|                                   -- Rush, "New World Man", on _Signals_    |
-------------------------------------------------------------------------------


=========================================================================
Date:         Wed, 13 Jul 88 09:41:52 IST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         CCAYOSI@TECHNION
Subject:      Re: forwarded virus seminar announcement
In-Reply-To:  Message of Tue, 12 Jul 88 15:17:51 EDT from <LUKEN@LEHIIBM1>

=========================================================================
Date:         Wed, 13 Jul 88 15:14:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         John Lundin Jr <LUNDIN@URVAX>
Subject:      VMS ZOO ok?

A version of ZOO for VAX/VMS arrived over the net yesterday on Info-VAX.. an
executable image, UUENCODEd.  ZOO is an archiver program.  Considering the
number of bad PKARC versions that are out there, can anyone vouch for this?

Anyone have source?

A quick check shows that it was probably written in C, and has many plausible-
sounding error messages near the beginning.

Here's the header info preceeding the uuencoded material:

>From:  BITNET%VTVM2::MAILER 11-JUL-1988 16:17
>To:    LUNDIN
>Subj:
>
>Received: From VTVM2(MAILER) by URVAX with Jnet id 8344
>          for LUNDIN@URVAX; Mon, 11 Jul 88 16:17 EDT
>Received: by VTVM2 (Mailer X1.25) id 8320; Mon, 11 Jul 88 16:07:31 EDT
>Date:         Mon, 4 Jul 88 15:30:43 MDT
>Reply-To:     [e-mail]
>Sender:       INFO-VAX Discussion <INFO-VAX@VTVM2>
>Comments:     <Parser> W: Invalid RFC822 field -- ".EDU". Rest of header
>              flushed.
>From:         ewilts%Ins.MRC.AdhocNet.CA%Stasis.MRC.AdhocNet.CA%UNCAEDU.
>              @CORNELLC.CCS.CORNELL
>To:           'John Lundin Jr' <LUNDIN@URVAX>
>
>As per the recent request for ZOO for VMS, I am including the following
>UUENCODED file of ZOO.EXE.
>
>[ actual file omitted ]

Thanks!                        -john

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
John Lundin, Jr.         VAX785::LUNDIN                     (UR/MCV Decnet)
Academic Computing       LUNDIN @ URVAX                            (BITNET)
University of Richmond   [e-mail]     (Internet)
Richmond, VA  23173      ...!rutgers{!psuvax1}!urvax.bitnet!lundin   (UUCP)

=========================================================================
Date:         Wed, 13 Jul 88 08:38:10 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Joe Simpson <JS05STAF@MIAMIU>
Subject:      Final (I hope) posting on Miami U. spring epidemic

In two earlier postings I described what we thought we knew about an
MS-DOS based virus epidemic at Miami.  We were afflicted with the
standard (non destructive) version of Brain with numerous complaints of
lost data.  As part of our early response we used rather draconian
measures to copy (some) user data from affected diskettes to clean
media.  We kept many of the origionals that were reported as defective.

These diskettes were sorted into categories, probably using Norton utilities.
A stratified sample was then subjected to more detailed analysis with the
following results:
1.  Some media were physically defective.
2.  Brain existed on some diskettes.  No mutated version of Brian was found
    using byte level comparision with a known standard Brain.


Conclusion:   There is no reproducible evidence that Miami was visited by
a virus that deliberately attemped to alter or destroy user data.  Fred Cohen
spent a morning with us at the height of our confusion and suspected a mutated
Brain.  We have been unable to corroborate this.

Critique of our performance:
1.  The draconian measures we took in the early days resulted in loss of user
    data.  Lack of a formal coordinating body and ignorance of the topic of
    computer viruses caused us to continue these measures longer than was
    desirable.
2.  Lack of awareness of the problem probably caused us to ignore very early
    warning signs resulting in the crisus occuring at our busiest time of
    year.
3.  Our efforts at communicating information about the virus were as accurate
    as practical, but most reports did not accurately describe the situation
    as currently understood.  Reporters made best efforts to be factual, but
    (at least in my opinion) were intimidated by the word "computer".  This is
    very puzzeling.  If you remove the word computer, they are more competent
    than most computer professionals to communicate public health information.
4.  In retrospect, it is easy to see that modification of "nominal" behavior
    at Miami before the epidemic would have severely reduced the cost.  In
    particular our habit of initializing with DOS provided the perfect
    "media" for Brain.

Notes:
1.  We were visited by two destructive viruses in the Mac world.
2.  There is some Mac software offering partial protection (Vaccine cdev)
    without seriously affecting the working environment (except for
    programmers).  There are also several programs designed to detect
    (obvious) viruses including virus detective and RX. These are cheap!
3.  We have yet to find anything good in the MS-DOS world, either to
    provide protection or diagnosis.
4.  Our Novel server based laboratories had very few internal problems.
    Whether this is due to lack of archetecture in MS-DOS or due to the
    characteristics of Brain is hard to ascertain.
=========================================================================
Date:         Thu, 14 Jul 88 07:36:26 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject:      Re: VMS ZOO ok?
In-Reply-To:  Message of Wed, 13 Jul 88 15:14:00 EDT from <LUNDIN@URVAX>

>A version of ZOO for VAX/VMS arrived over the net yesterday on Info-VAX.. an
>executable image, UUENCODEd.  ZOO is an archiver program.  Considering the
>number of bad PKARC versions that are out there, can anyone vouch for this?

It's not usually considered wise to accept (blindly) any executable image
from an unfamiliar (untrusted) source.  At the very least, follow up with
the people who posted the file to find out where they got it, and try to
obtain an original copy directly from the author.  Of course, this is
just my opinion...

Ken

Disclaimer: I don't know what a disclaimer is, and I don't claim to either.

Kenneth R. van Wyk                    Hobbes: Wow, buried treasure right
User Services Senior Consultant               where you said it'd be!  A
Lehigh University Computing Center            wallet full of money!
Internet: <[e-mail]>  Calvin: Yeah, it's Dad's.  I buried it
BITNET:   <LUKEN@LEHIIBM1>                    here last week!
=========================================================================
Date:         Thu, 14 Jul 88 09:05:57 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "David M. Chess" <CHESS@YKTVMV>
Subject:      Posting from Joe Simpson on Miami U. spring epidemic

> 3.  We have yet to find anything good in the MS-DOS world, either to
>     provide protection or diagnosis.

Have you examined/tried things and found them wanting?  If so, it
might be interesting/informative to post something like mini-reviews
to the list.   I'm sure lots of other folk are on the same quest...

DC

* Disclaimer: Who, me?=========================================================================
Date:         Mon, 18 Jul 88 10:53:29 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         AL148859@TECMTYVM
Subject:      Virus on the PC.


    Hello,

         Can anybody sendme a technical explanation of the "Brain"
    virus?   I'll apreciate the help..
         If you know another virus for the IBM-PC send to me an
    explanation too.

                        Thank's!


Juan Gabriel Ruiz Pinto
AL148859@TECMTYVM
Ing. Sistemas Electronicos
I.T.E.S.M.
=========================================================================
Date:         Mon, 18 Jul 88 10:40:14 PLT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Andrew Vaught <29284843@WSUVM1>
Subject:      Virus Discussion

The list has sure been quiet for a while. Have we said all there is to say
about viruses?


                   Andy
=========================================================================
Date:         Mon, 18 Jul 88 12:54:19 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Len Levine <[e-mail]>
Subject:      Re: Virus Discussion
In-Reply-To:  Message from "Andrew Vaught" of Jul 18, 88 at 10:40 am

>
>The list has sure been quiet for a while. Have we said all there is to say
>about viruses?
>
>
>                   Andy
>
I had noted that too.  Seemed like my wire had been cut.

:-)


+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Leonard P. Levine                  e-mail [e-mail]    |
| Professor, Computer Science                Office [phone]    |
| University of Wisconsin-Milwaukee          Home   [phone]    |
| Milwaukee, WI 53201 U. S. A.               Modem  [phone]    |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

=========================================================================
Date:         Mon, 18 Jul 88 14:45:15 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Joe McMahon <XRJDM@SCFVM>
Subject:      Re: Virus Discussion
In-Reply-To:  Message of Mon, 18 Jul 88 10:40:14 PLT from <29284843@WSUVM1>

>The list has sure been quiet for a while. Have we said all there is to say
>about viruses?

No, but I DO think we have (along with others) made it plain that "hangin' 's
too good for them varmints." Either we've scared a lot of people away from
viruses by our immediate and agressive response (could be), or they've been
working on their new viruses (alas - even more likely to be).

--- Joe M.
=========================================================================
Date:         Mon, 18 Jul 88 16:29:24 CST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Claudia Lynch <AS04@UNTVM1>
Subject:      Re: Virus on the PC.
In-Reply-To:  Message of Mon, 18 Jul 88 10:53:29 EDT from <AL148859@TECMTYVM>

There are some articles in the CCNEWS archives. You can get these by
issuing the command GET filename filetype to LISTSERV@BITNIC. These
articles are: BRAIN McPART_T , VIRUS CERNY_J and VIRUS SHEEHA_M.
I hope these were of some help.

Claudia Lynch
=========================================================================
Date:         Mon, 18 Jul 88 19:04:37 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         2662@DB0TUZ01


GET DIRTY DOZEN



=========================================================================
Date:         Tue, 19 Jul 88 12:52:53 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject:      Forwarded virus hype editorial, and some random comments


Greetings,

First of all, I've noticed that VIRUS-L has gained many subscribers in
the past week or so since it was announced in the NETMONTH newsletter here
on BITNET; welcome all!  Around the end of this month, I'll be sending
out my monthly info sheet which should clear up some questions which you
may have, such as, "how do I get files from this LISTSERV?".

Secondly, a number of people have noted that VIRUS-L traffic has subsided
quite a bit.  I'd imagine that this is partly due to the fact that many
university students have gone home for the summer, but perhaps not.  I
don't think that the subject has been exhausted by any means.  We'll see...
Let's see some participation out there!

Finally, this next item is a editorial comment from an anti-software
vendor.  The editorial was distributed via Compuserve, and forwarded
to me verbatim.  Note that it is not an endorsement, merely an opinion
from the vendor.


Ken van Wyk


-------- begin editorial ---------



CompuServe                 IBMSW

IBM Software Forum Forum Menu

#: 197283 S9/Hot Topic (S)
    09-Jul-88  16:53:51
Sb: #Virus Hype
Fm: rg software 70701,2561
To: ALL


VIRUS HYPE

Since I'm a new participant in this forum group, I'd like to introduce myself:

        Raymond M. Glath
        President
        RG Software Systems, Inc.
        2300 Computer Ave.
        Willow Grove, PA 19090

        [phone]

We are a 4 year old developer/publisher. Our products are "DISK WATCHER" which
includes anti-virus logic among its many features, and the "PC TRACKER" systems
for managing pc resources.

Between various articles in INFOWORLD and discussions in CIS forums, Steve
Gibson has heartily promoted:

        The C-4 product from Interpath (according to Steve, "the only
        product to beat all viruses known to the NBBS");

        The "not-for-profit" "National Bulletin Board Society" with its Virus
        Simulator, VIRSIM;

        and in a recent message to Thomas Thornbury of Software Directions,
        the "industry-wide coalition of independent anti-viral software
        publishers", information on which may be obtained from the individual
        Steve referenced at the NBBS.

Some interesting facts that we've discovered:

1. The 1st time we ever saw the NBBS referenced in print was in an editorial
column in PC WEEK approximately 1 month after Interpath announced their
anti-virus product. This editorial stated that the NBBS was selling a virus
simulator product for $79.95.

2. Interpath and the NBBS co-incidentally share the exact same address, however
published reports never seem to link these two? groups in any way other than
Steve Gibson's report that C-4 is the only product that defeats ALL the viruses
on the NBBS.

3. One of our customers had contacted the NBBS and received a disk from them
which contained: the virus simulator... VIRSIM; an actual working virus that
attacks COM files; and two dis-assembled/commented virus programs... The BRAIN
and the ISRAELI viruses.


#: 197284 S9/Hot Topic (S)
    09-Jul-88  16:56:49
Sb: #Virus Hype
Fm: rg software 70701,2561
To: ALL

(Continuation from 197283)

4. Upon request from our customer, we analyzed the VIRSIM simulator product and
discovered that VIRSIM makes a number of erroneous assumptions when performing
its "virus attacks". To wit:

    a. It considers the mere OPENing of a COM, EXE, or SYS file to be a virus
  attack. The fact that a file is OPENed doesn't change the file in any way.
  You must WRITE TO THE FILE TO CHANGE IT.

       WRITING to one of these files would indicate a valid virus attack
  condition. OPENing, without ever WRITING is not a virus attack condition,
  but rather a "false alarm".

    b. During several VIRSIM "attacks", VIRSIM does not check the error
  return conditions properly after the "attack", and therefore erroneously
  reports successful attacks that have, in reality, failed.

5. Steve also told Thomas Thornbury to contact an individual at the NBBS for
information on the newly formed "industry-wide coalition of independent
anti-viral software publishers". In fact, the president of INTERPATH phoned our
company stating that HE was forming this group and solicited our membership.

Due to the conditions outlined above, we have chosen to NOT AFFILIATE with this
"coalition", and must question whether or not its formation is just another
form of hype to keep the virus fuel burning in the pressrooms.

Viruses are real.

The threat is there.

The extent of the threat is totally unknown at this time. It may get serious
and it may not. We need more substance and less hype in the press.

If the world must have a virus simulator to evaluate anti-virus products, then
lets have one developed by someone totally isolated from anti-virus publishers;
lets have it certified by a professional software evaluation company; and lets
insure that it is neither able to be easily turned into a real virus, nor
documented to a level that it becomes a "how to" guide for virus writers.

Comments welcome...

Ray Glath
=========================================================================
Date:         Tue, 19 Jul 88 13:21:00 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         GILL@QUCDNAST
Subject:      RE:  VMS ZOO

John Lundin writes

>A version of ZOO for VAX/VMS arrived over the net yesterday on Info-VAX.. an
>executable image, UUENCODEd.  ZOO is an archiver program.  Considering the
>number of bad PKARC versions that are out there, can anyone vouch for this?

>Anyone have source?

>A quick check shows that it was probably written in C, and has many plausible-
>sounding error messages near the beginning.

     Our system guru downloaded this file yesterday and found out that
it did not work - the resulting file had the wrong format for our uVAX
to recognize.  He theorizes that this may have something to do with the
fact that we have no C or C libraries on our machine, but isn't positive.
It is not a virus as far we know - it just doesn't work.

     If anyone gets a ZOO for the VAX up and running, e-mail me.  We
will be interested.

                                          -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Arnold Gill                              | If you don't complain to those who  |
Queen's University at Kingston           | implemented the problem, you have   |
gill @ qucdnast.bitnet                   | no right to complain at all !       |
                                          -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
=========================================================================
Date:         Tue, 19 Jul 88 10:38:44 PLT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Andrew Vaught <29284843@WSUVM1>
Subject:      VIRSIM


I think that the idea of keeping a "Virus Simulator" around is a pretty
useless idea since having your virus-detector program `discover' VIRSIM's
`attacks' only give a false sense of security. A genuine virus would probably
much trickier. This makes me wonder-- have we seen any viruses yet that are
designed to fools any of the popular packages around? It would seem to me that
a virus has to be small enough to hide somewhere, and this would prevent
esoteric anti-detection detection countermeasures.

As for VIRSIM, shelve it. It is useless.

           Andy
=========================================================================
Date:         Wed, 20 Jul 88 02:44:41 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         me! Jefferson Ogata <OGATA@UMDD>
Subject:      simulators

> As for VIRSIM, shelve it; it is useless.

Virus simulators are viable ways to test virus protection software.
If I were testing it, one thing I wouldn't do is use REAL viruses.
The majority of virus problems presently are caused by known viruses,
such as the BRAIN virus, and mutations therefrom.  An appropriate way
to test software designed to protect against such attacks is to simulate
the attacks with an easily controlled substitute.  Protecting against
new and innovative viruses would be virtually impossible; nevertheless,
we needn't discard the notion of virus simulation for known strains.
Virus simulation is really quite close in principle to vaccination.
Vaccines are designed to stimulate immune system response to a disease
without incurring any real danger to the patient.  Virus simulators are
a good test for virus-protection software, as they also incur no real
danger to the patient (hopefully).  Should we stop manufacturing influ-
enza vaccines just because the flu changes every year?

I am certainly not endorsing this particular simulator, VIRSIM, as good
evidence has been presented that it may be a corporate marketing ruse.
There are other simulators out there.  I'd say use them in good health.

- Jeff
=========================================================================
Date:         Wed, 20 Jul 88 12:57:17 SET
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Christian J. Reichetzeder" <REICHETZ@AWIIMC11>
Subject:      Re: VM/CMS viruses
In-Reply-To:  Message of Fri, 24 Jun 88 10:07:00 URZ from <BG0@DHDURZ2>

I don't know if the following scenario has already been addressed.
*-*
Use of PCs both as PC and Terminal  is wildly increasing at our site. More and
more products  are available  to connect  to hosts  (ECF, FBSS,  Kermit, ...).
Future plans for our site include LAN,  bridges to EtherNet and who knows what
else.
There  will (must)  also be  some "public"  PCs for  software-demo, assitance,
utilities (e.g. copying diskettes to different format), students, ...
REMARK: most of the PCs are  "outside" our institution, i.e. other Institutes/
        Clinics connecting to the mainframe own those PCs.
*-*
I fear that there  is a "good" chance that (almost) all  PCs get infested from
the public  ones - not  necessary by deliberate action.  It could come  from a
user  who caught  a virus  by accident  and uses  the public  PC to  copy some
diskettes.
What if a  Trojan connection program (e.g. 3270 emulation)  spreads around? It
could steal  *host* passwords  and make  use of the  LAN to  send them  to the
hacker. It could also be used to infest the host (CMS in our case).
*-*
Any  comments, suggestions,  experiences,  war stories,  ...??? Some  specific
questions:
  * is it better if the "public" PCs have *NO harddisk* ?
  * should we offer host access in "public" PCs or not ?
  * anyone ever heard of installing a "controlled" PC as a "bait" ?
Christian
=========================================================================
Date:         Wed, 20 Jul 88 07:38:10 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject:      Re: VM/CMS viruses
In-Reply-To:  Message of Wed, 20 Jul 88 12:57:17 SET from <REICHETZ@AWIIMC11>

>What if a  Trojan connection program (e.g. 3270 emulation)  spreads around?
>  * is it better if the "public" PCs have *NO harddisk* ?
>  * should we offer host access in "public" PCs or not ?
>  * anyone ever heard of installing a "controlled" PC as a "bait" ?

This sort of thing is certainly a very real problem, primarily at universities
which have publically accessible micros.  It turns out that these public
micros are probably about the best incubating environment that you could
imagine for a virus or trojan terminal emulator, etc.  Here at Lehigh, we've
done the following to try to reduce this risk:

1) All public micros are dual floppy machines; most of which are connected
   to LANs (Novell on 3COM boards).
2) All boot disks (with Novell software on) are notchless disks, and they
   contain nothing other than the operating system boot files and the
   Novell software.
3) All Novell hard disks (on the file servers) are read only, with the
   exception of a scratch area where users can place temporary files.
4) The scratch areas get cleaned (i.e., erased) periodically by our student
   employees.
5) Users logging into the LAN are not automatically placed in the scratch
   directory.  (Recall that, in MS-DOS, the current working directory is
   always searched for executables before the PATH is...)

The above methods are probably not infallible (sp?), but what is?  Yes, I
do think that it is worthwhile to have public micros, but you *HAVE* to take
some basic precautions.  Offering host access from your public micros should
be a must; at least, depending upon how your computing facility is set up.
We have very few data terminals any more; almost all mainframe access is via
PCs connected to our digital voice/data PBX.

As far as setting up a controlled PC as bait; it sounds rather expensive,
but what form of bait did you have in mind?


Ken

Kenneth R. van Wyk                    From the Devil's Dictionary:
User Services Senior Consultant          Barometer - an ingenious device
Lehigh University Computing Center         designed to inform the user what
Internet: <[e-mail]>       the weather is.
BITNET:   <LUKEN@LEHIIBM1>
=========================================================================
Date:         Tue, 19 Jul 88 19:27:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         [e-mail]
Subject:      Re: Forwarded virus hype editorial, and some random comments
In-Reply-To:  Message of 19 Jul 88 12:52 EDT from "Kenneth R. van Wyk"


>Since I'm a new participant in this forum group, I'd like to introduce
>myself:
>
>        Raymond M. Glath
>        President
>        RG Software Systems, Inc.
>        2300 Computer Ave.
>        Willow Grove, PA 19090

Nice; courteous; however, we have already met.

> a. It considers the mere OPENing of a COM, EXE, or SYS file to be a
>    virus attack. The fact that a file is OPENed doesn't change the
>    file in any way.
>    You must WRITE TO THE FILE TO CHANGE IT.

True.  However, a simulator need not do everything that the real thing
must do.  Flight Simulator does not fly either, but it does simulate the
externals.  A virus simulator need not necessarily infect.  If it would
present the same results to a virus protection program that a virus
would, then it has probably met the requirement for such a program.

>Due to the conditions outlined above, we have chosen to NOT AFFILIATE
>with this "coalition", and must question whether or not its formation is just
>another form of hype to keep the virus fuel burning in the pressrooms.

More basic, it seems to me, is whether or not there is any requirement
for such an organization.  Even if "caveat emptor" did not apply here,
there does not appear to be much evidence that people are being ripped
off.  It seems a little early to declare the market full and all of the
invention done.

>If the world must have a virus simulator to evaluate anti-virus
>products, then lets have one developed by someone totally isolated from
>anti-virus publishers; lets have it certified by a professional software
>evaluation company; and lets insure that it is neither able to be easily
>turned into a real virus, nor documented to a level that it becomes a
>"how to" guide for virus writers.

Certainly, we should avoid conflict of interest.  It is useful to have a
forum such as this to publicize any potential ones that we identify.
That having been said, we can likely afford what we have seen to date.

Still, there does seem to be some unseemly haste here somewhere.

Regards, Bill

William Hugh Murray, Fellow, Information System Security, Ernst & Whinney
2000 National City Center Cleveland, Ohio 44114
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840
=========================================================================
Date:         Wed, 20 Jul 88 12:00:09 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Lois Buwalda <LOIS@UCF1VM>
Subject:      How to warn inexperienced users about viruses

Hi!  I'm in the process of writing a BITNET help guide for beginning
computer users.  Since I have to explain to these users how to send and
receive files, I would also like to include a section on viruses.  Thus,
I was wondering what you guys think beginning users should be told about
them (i.e., what can be done to minimize the spread of them, etc.).
Please keep in mind that these people know very little about computers,
so telling them to carefully read through all programs before running
them wouldn't help a whole lot.  Anything else I can tell them besides
the obvious "don't receive any files from people that you don't know"?

If you want to reply directly to me, I will summarize the responses over
the list later.  Thanks!

Lois
=========================================================================
Date:         Wed, 20 Jul 88 15:26:51 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Steve <XRAYSROK@SBCCVM>
Subject:      Re: VM/CMS viruses
In-Reply-To:  Message of Wed, 20 Jul 88 12:57:17 SET from <REICHETZ@AWIIMC11>


>What if a  Trojan connection program (e.g. 3270 emulation)  spreads around? It
>could steal  *host* passwords  and make  use of the  LAN to  send them  to the
>hacker. It could also be used to infest the host (CMS in our case).

   I'm new to this list.  I wanted to point out that in regard to corrupted
terminal emulators that steal passwords and send them to a "hacker", this
probably is not the way it would happen.  Such an emulator would have to
have the "address" of the "hacker" in order to forward passwords to him,
right?  That leaves the "hacker" vulnerable to discovery and identification,
and most intelligent "hackers" would not take such a risk.  On the other hand,
the program could store userids and passwords, hidden on disk somewhere, and
the "hacker" could later come along and extract this information.  Or maybe
such an emulator could be set up to respond remotely to the queries of the
person who planted it.

Steve
=========================================================================
Date:         Wed, 20 Jul 88 20:03:40 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         [e-mail]
Subject:      Write protect hardware

Is there any way to design code so that a disk write to a write-protected
disk will NOT generate a write error message?
=========================================================================
Date:         Wed, 20 Jul 88 20:05:17 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         [e-mail]
Subject:      Getting a handle on size

I just thought of a purely hypothetical question which may or may not be of
value to this discussion. Supposing you were the ideal computer user and
initialised your system by checksumming all your files initially followed by
regular repeats, and using programs like CHK4BOMB, BOMBSQAD, and/or FSP
regularly. You also believe in the value of a well-placed write protect tab
and have the latest software protection for your hard drive. You have also
made your important files read-only using some attribute changing utility.

Along comes virus writer X who wants to destroy your system for perverted
kicks. What type of virus could this person design to circumvent all these
measures, what is the minimum size it could possibly be, and how much would
it slow down processing time (to the detectable level? not at all?)?
Obviously almost no one has write protect tabs on their disks all the time.
=========================================================================
Date:         Wed, 20 Jul 88 16:54:47 MEX
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         SISTEMAS@VMTECMEX

Hi there:
         I'm new to the list but I think it's real good.
         I would like to get a virus simulator to evaluate
         a protection developed here.I'd like it better if
         it's an "independent" simulator ( not VIRSIM ).
         Any suggestions? ( please be specific about it ).
         Thanks in advance for your valuable help.

         Arturo Torres. Soft.Eng.Dep. ITESM Mexico City. Mexico.
=========================================================================
Date:         Thu, 21 Jul 88 03:11:21 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Amanda B Rosen <[e-mail]>
Subject:      Re: Write Protect Hardware

David Slonosky asks:
>Is there any way to design code so that a disk write to a write-protected
>disk will NOT generate a write error message?

This could be interpreted two ways.
1) If you mean, can I fool the virus into thinking it has successfully
   altered my disk, the answer is yes. Whether the disk is protected by
   software or hardware (write lines cut or whatever), it should be very
   easy to replace the disk-writing trap (or interrupt in MS-DOS) so that
   writes simply do nothing. However, this is useless against sophisticated
   viruses which can easily see if the trap or interrupt has been replaced.
   Also, it is easy for a virus to read-after-write to tell for sure. I am
   not aware of any such viruses, but some such probably do exist.
   Of course, if your disk is hardware write-protected, the only benefit to
   fooling the virus is that it may subsequently reveal itself. However, if
   you're going to the trouble of hooking the write calls, you might as well
   add some user alert to the code while you're at it. Thus, I don't think
   that fooling the virus this way is significantly helpful, except against
   very simple ones.

2) If you mean, can I prevent MY programs from crapping out when they try it,
   the answer is the same. Do the same thing. In this case, there can be
   some benefit (your application doesn't die, unless it depends in some
   critical way on the data it just wrote...)

/a
=========================================================================
Date:         Thu, 21 Jul 88 02:37:00 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Back off man, I'm a scientist..." <FRANK@LOYVAX>
Subject:      P.S.

P.S.   About snatch.com, we never actually used this program against the
       world at large.  We did test it on our girlfriends, though.



                               Frank
=========================================================================
Date:         Wed, 20 Jul 88 22:39:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Brian Holmes <BHOLMES@WAYNEST1>
Subject:      Re: Write protect hardware
In-Reply-To:  Your message of Wed 20 Jul 88 20:03:40 EDT

It is very easy to tell if a disk is write protected through
specific calls to the operating system, so yes you can design
code to not issue a write protect error, if a disk has been
write protected.

*******************************************************************
*    Brian Holmes                  \    /                ___      *
*    Wayne State University         \/\/su              |   |     *
*    Detroit Michigan                               ____|   |____ *
*                                                   |   |   |   | *
*  BITNET   : BHOLMES@WAYNEST1                      |   |   |   | *
*  INTERNET : [e-mail]       |   |   |   | *
*  UUCP     : {UMIX|ITIVAX}!WAYNE-MTS!BRIAN_HOLMES  ============= *
*******************************************************************
=========================================================================
Date:         Wed, 20 Jul 88 22:25:36 CST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         James Ford <JFORD1@UA1VM>
Subject:      HDSENTRY

     I downloaded HDSENTRY from a bbs here in town and decided to give it
a try.  (HDSENTRY is suppose to be a h-drive "write-protect" tab...)  It
came with a DOC, COM and ASM file.............

Well, I backed up a directory and then ran the program.  I then proceded to
DEL *.* and sat  back.  I got the message WARNING!  TRYING TO DELETE ...etc.
and said to my self, "Hey, this might do the job."  I then did a directory and
found no files at ALL.  However, after re-booting, the files re-appeared.

My question:  Why does HDSENTRY do this?  Are some stack pointers off or what?
I have a copy of the ASM file, but don't know enough about assembly to check
on it.  Any takers?  I'm using an IBM PS/2 M30 w/20M.


                                 James Ford
                                 [e-mail]
=========================================================================
Date:         Thu, 21 Jul 88 02:34:00 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Back off man, I'm a scientist..." <FRANK@LOYVAX>
Subject:      Password Snatchers.


   The problem of password stealing isn't limited to hacked software that links
PC's to mainframes.  This problem can occur from dumb-terminals hard-wired
directly to the mainframe.

   Last semester, a few of us wondered if it would be possible to snatch peoples
Usernames and Passwords.  After arguing the matter for about 10 minutes, we
decided that the only way to determine if it were possible or not, was to try
to write one for ourselves...

   The basic idea behind our snatcher.com was to have a terminal appear to be
unused and let the Victim "log in" there.  We simulated the system password
request mechanism and When the person typed in his/her username and password we
intercepted it and wrote them out to a file.

   The whole program took only an hour to write, and looked and felt almost
exactly like the real thing.  It did, however, have two faults.  The first
was that after you got finished typing in your password, snatch.com would
write out "user authorization failure." It would, then ask for your username and
password 2 more times.  After the 3rd "Failure", snatch.com would cut it's own
process enabling you to log in for real.  -- After a while, people should start
to catch on to what was happening. (We could, of course, have set hosted the
victim, but that would be asking for trouble.)  The other problem, was that if
at the Username prompt, you hit a bunch of returns quickly, there was a
slightly noticable delay (1/8 second) until the next username prompt came up.

   We figure that this program could fool all non-frequent users, a good deal
of the frequent users, a couple consultants, and the System Programmers on
one of their bad days.

   If we had actually planned to use snatch.com, we would have eliminated the
possibility of being caught by running snatch.com from some obscure user's
account.  At Loyola, that's pretty easy to do since passwords are set to the
owner's school id number, and most people don't ever bother to change their
passwords... We would have snatch.com write to some innocent sounding file in
that user's account.

   As far as protection goes for this sort of program, I can think of three
ways to guard against this.  First, have the System Manager run a batch job
that will stop any interactive process that has been laying dorminant for a
given period of time.  The next are specific to my program.  Watch out for
unusual responses (cursor jumps or time lags).  Finally, if you get a user
authorization failure, make sure that when you finally do get logged in,
you get the proper number of login failure messages since your last login,
otherwise, changing your password would be in order...



                               Frank Gauthier
                               Academic Computing.
=========================================================================
Date:         Thu, 21 Jul 88 09:58:32 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         SHERK@UMDD
Subject:      Write protect hardware
In-Reply-To:  Message received on Wed, 20 Jul 88  20:12:09 EDT

=========================================================================

>Is there any way to design code so that a disk write to a writeprotected
>disk will NOT generate a write error message?

Yes. It is trivial in fact. The error message one sees is a DOS function
and not a bios function.
=========================================================================
Date:         Thu, 21 Jul 88 18:09:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         [e-mail]
Subject:      Re: Password Snatchers.
In-Reply-To:  Message of 21 Jul 88 03:34 EDT from "Back off man,
              I'm a scientist..."


>The basic idea behind our snatcher.com was to have a terminal appear
>to be unused and let the Victim "log in" there.  We simulated the system
>password request mechanism and When the person typed in his/her username and
>password weintercepted it and wrote them out to a file.
This attack belongs to the class called spoofs.  It is well known and
documented.  Along with eavesdropping, it is one of the reasons that
re-useable passwords should be limited to systems in which the terminal
and link are dedicated to the application and in which there is no user
programming (yes, Virginia, there really are such systems.)  In other
systems serious consideration should be given to the use of one-time
passwords.  (While there are other defenses against such attacks, they
all rely upon knowledgeable and diligent users.  These are known to be
expensive.)

William Hugh Murray, Fellow, Information System Security, Ernst & Whinney
2000 National City Center Cleveland, Ohio 44114
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840
=========================================================================
Date:         Thu, 21 Jul 88 21:08:00 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Back off man, I'm a scientist..." <FRANK@LOYVAX>
Subject:      Forwarded submission.  Passwords & Thug

From:   Jnet%"KERRY@TUFTS" 21-JUL-1988 20:38
To:     JNET%"Frank@LOYVAX",KERRY
Subj:   Passwords & THUG

Received: From TUFTS(KERRY) by LOYVAX with Jnet id 5372
          for FRANK@LOYVAX; Thu, 21 Jul 88 20:37 EST
Date:     Thu, 21 Jul 88 20:35 EST
From:     <KERRY@TUFTS>
Subject:  Passwords & THUG
To:       Frank@LOYVAX
Original_To:  JNET%"Frank@LOYVAX",KERRY

Couldn't help smiling at your suggestion that the System Manager run some
job which logs out inactive jobs.  We've put exactly that into place here
at Tufts.  It's called THUG (and I even forget why, although one of my staff
wrote it!), and does just that sort of logging out.  It even provides
for two classes of exceptions.

Is anyone there interested?

Kerry Dugan
Systems Programming
Tufts University
Medford, MA
[e-mail]
=========================================================================
Date:         Fri, 22 Jul 88 07:37:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         [e-mail]
Subject:      Presentation by F. Cohen




On  Wednesday,      July  20, 1988      at  the IBM Watson  Research
Laboratory at Hawthorne, New York, Fred Cohen gave a lecture
titled "Models of Practical Defenses  Against Viruses."  The
lecture drew well from both  within the lab and  from  among
the  members  of this forum.  I enjoyed both the content and
style  of  the       lecture.  I  was   disappointed,   but  not
surprised,  that he had  no magic to offer.  I am  sure that
others will want to report on what  Fred  said.  I  can only
report on what I heard.

He  began by repeating        his definition      of a  virus  from an
earlier  presentation in the same forum.  He  also  gave his
general purpose virus program which  contains  the line  "IF
"trigger-pulled" THEN DO "damage."

He suggested that most defenses for viruses are combinations
of the following:

*   detect by appearance
*   detect by behavior
*   detect by change

He asserts  that  detection  by  appearance is    undecidable.
Detection by behavior involves too many  false positives and
false     negatives;  it      is  disruptive.   He   asserts          that
detection of change may be costly, untimely, easy  to forge,
and at any rate, fails to deal with all attacks.

He  suggested that  ultimately we deal  with  viruses  by  a
combination of limiting sharing, limiting transivity, and by
limiting functionality and  generality.  He suggests a world
comprised, mostly, of application machines.  In such a world
we  can  enjoy      most of  the  benefits        of  computers  while
limiting  the  inherent risk.  Specifically,  he  recommends
that we limit methods of interpretation.

[Comment:  Your reporter has long promoted such a strategy [
Computers  & Security 2  (1983) 16-23,  "Computer  Security:
Observations on the  State  of the Technology," ]  To put it
another way, Von Neumann was wrong;  that is,  programs  are
not like other data, should  not  be  modifiable, and should
not   share  storage   with  modifiable  data  objects.  For
example, in  the IBM System/38          programs  are strongly typed
data  objects.      The  type,  program,   cannot be  changed.
Modifiable data  types cannot be executed.  A program may be
replaced in toto, but that results in a change in  its fully
qualified name.  This tends to make surreptitious changes to
the program difficult indeed.  This is not an assertion that
S/38 is not vulnerable to viruses, but rather an example  of
how  restricting generality can  reduce the vulnerability or
increase  the       attackers  work  factor   and  increase  his
requirement  for special knowledge.  A counter example might
be the inclusion of BASIC or REXX language interpreters in a
system,  not restricitng access  to them, while not treating
their input as executables.]

Cohen proposes a strategy which  he  calls "Complexity Based
Integrity Maintenance."  He asserts that programs must check
things    upon  which  they rely,  and  which are  subject  to
change.  This  includes their data, their own  content,  the
operating system, micro-code, hardware and physics [in order
of increasing  stability].  The check function must  be hard
to  identify,  locate,        and forge.  The  check function must
verify everything, most things, relevant things, or "however
well we can  do."  Of course, the check function  computes a
short, but difficult to reverse,  function of  the object to
be checked .

He demonstrated a  checker  called ASP  (Automatic  Software
Protection).  It  checks  the  boot  block,  OS  files,  and
dependencies.  It  detects  and  reports  all  changes.  [My
inderstanding is that it works in  a  manner similar to that
of Vaccine by FoundationWare (not to  be confused with other
programs of the same name.)]

Questions focused  on  the  windows  of vulnerability in the
demonstration       system.  Of   course,  Cohen  only  promised
defenses, not perfect security.  There  was  some suggestion
that "trusted" systems  would improve  the  effectiveness of
Cohen's  defense,  ease  its implementation, and reduce  its
cost.  Of  course this assumes          that  "trusted"  systems are
easier    to  achieve  and  cheaper   than  Cohen's  strategy;
undecidable.

Fred Cohen demonstrated both  comprehension and  wit.  I  am
satisfied  that  his description  of  the  problem  and  the
solution  is both informed  and useful.  We will  find      that
whatever strategy we adopt to deal  with viruses, if deal we
must, will have been anticipated by his work.

William Hugh Murray, Fellow, Information System Security, Ernst & Whinney
2000 National City Center Cleveland, Ohio 44114
21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840
=========================================================================
Date:         Fri, 22 Jul 88 09:54:27 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         me! Jefferson Ogata <OGATA@UMDD>
Subject:      HDSENTRY

Not knowing much about actual MS-DOS specifics, I can present some
conjecture on the operation of the "hardware write-protect tab" you
mentioned.

In many operating systems, disk allocation tables and
directory information are kept in RAM.  After a disk write, the updated
directory info is written to the disk.  If some program disables all
write access to a disk without informing the OS, the OS is likely to
be unaware that its disk writes are failing.  The practical upshot is
that while a directory listing from the OS indicates some files have
been changed or erased, the actual contents of the disk have not been
altered.  The OS's dir is based on its belief of what is on the disk.
When the machine is rebooted, it will reload the directory info from
the disk, which will still contain the old data.

I imagine that MS-DOS keeps the hard drive directory info in RAM with
periodic updates.  Note that floppy dirs get checked all the time in
case you switched disks while the machine wasn't looking.  I still
prefer the CP/M method of dealing with floppies: if you switched the
disk, it's R/O until you type a ctrl-C.  The niceness about this is
that the OS doesn't have to look at the disk every time you ask for a
directory, it just spouts off what was there the last time.

- Jeff
=========================================================================
Date:         Fri, 22 Jul 88 13:32:39 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Len Levine <[e-mail]>
Subject:      Re: Password Snatchers.
In-Reply-To:  Message from "[e-mail]" of Jul 21, 88 at 6:09 pm

>>The basic idea behind our snatcher.com was to have a terminal appear
>>to be unused and let the Victim "log in" there.  We simulated the system
>>password request mechanism and When the person typed in his/her username and
>> ...
>This attack belongs to the class called spoofs.  It is well known and
>documented.  Along with eavesdropping, it is one of the reasons that
>re-useable passwords should be limited to systems in which the terminal
>and link are dedicated to the application and in which there is no user
>programming (yes, Virginia, there really are such systems.)  In other
>systems serious consideration should be given to the use of one-time
>passwords.  (While there are other defenses against such attacks, they
>all rely upon knowledgeable and diligent users.  These are known to be
>expensive.)
>
>William Hugh Murray, Fellow, Information System Security, Ernst & Whinney
>2000 National City Center Cleveland, Ohio 44114
>21 Locust Avenue, Suite 2D, New Canaan, Connecticut 06840
>

On the other hand, there are systems that detect a loss of DTR (pin 24)
and can log out a user who tries this spoof.  We have used such systems
for some time now.  When a user tries to set up a trap like this, the
new user can only be nailed if he or she does not turn off the terminal
before logging in.


+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Leonard P. Levine                  e-mail [e-mail]    |
| Professor, Computer Science                Office [phone]    |
| University of Wisconsin-Milwaukee          Home   [phone]    |
| Milwaukee, WI 53201 U. S. A.               Modem  [phone]    |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

=========================================================================
Date:         Fri, 22 Jul 88 08:22:18 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Joe Simpson <JS05STAF@MIAMIU>
Subject:      Re: VM/CMS viruses
In-Reply-To:  Message of Wed, 20 Jul 88 12:57:17 SET from <REICHETZ@AWIIMC11>

>I fear that there  is a "good" chance that (almost) all  PCs get infested from
>the public  ones - not  necessary by deliberate action.  It could come  from a
>user  who caught  a virus  by accident  and uses  the public  PC to  copy some
>diskettes.

At Miami we found that PC's serving software on LAN's were resistant to
infection.  Frequently LAN software offers access features like execute only.
It would appear to be a bit more difficult to spread a virus accross a LAN
set up to serve software with no write access.  Perhaps your LAN propagation
could ammelorate your other concerns.
=========================================================================
Date:         Sat, 23 Jul 88 07:02:26 mdt
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
Comments:     Warning -- original Sender: tag was
From:         Bill Kinnersley <[e-mail]>
Subject:      Amiga Viruses

Does anyone out there have any experience with viruses on the Amiga?
=========================================================================
Date:         Sat, 23 Jul 88 12:48:00 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Steve Hyatt <SGHYATT@UALR>
Subject:      RE: Amiga Viruses

Bill,
     I have some experience with them. Which virus are you having problems with?


Steve Hyatt
Bitnet Address: SGHYATT@UALR
=========================================================================
Date:         Mon, 25 Jul 88 17:54:59 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         [e-mail]
Subject:      ROM Bios

What is ROM Bios? What are legitimate reasons for a program using it/them?
What are illegitimate reasons for the same? Enquiring minds want to know...
=========================================================================
Date:         Mon, 25 Jul 88 18:14:00 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Back off man, I'm a scientist..." <FRANK@LOYVAX>
Subject:      Rom Bios


> What is ROM Bios? What are legitimate reasons for a program using it/them?
> What are illegitimate reasons for the same? Enquiring minds want to know...

Rom Bios stands for Read Only Memory Basic Input Output Services.

Basically, Bios contains the routines that run all of your PC's I/O devices, inc
luding
the Monitor, and Disk Drives...

DOS also supplies functions that do many of the same things.

I suppose "Illegimate" uses are the nasty low-level programs we've been
talking about...

                                  Frank

=========================================================================
Date:         Tue, 26 Jul 88 09:59:23 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject:      request for opinions on future...


Greetings all,

As the virus world seems to have quieted down (at least here in the
Academic community) over the summer, I'm interested to hear what people
think will happen in the Fall and subsequent semesters as far as viruses
are concerned.  Do you think that all the publicity has enticed some
would be wrong doers into working on some super duper virus over the
summer, only to be released upon their return to college?  Or is this
too cynical an outlook?  Have we seen the end of viruses?  Perhaps all
of the potential virus writers have decided to change their ways?  A
lot of people who I've spoken with feel that a lot of virus writing
efforts are taking place this summer; I hope that they're wrong.

Opinions?

Ken

Kenneth R. van Wyk                    From the Devil's Dictionary:
User Services Senior Consultant          Barometer - an ingenious device
Lehigh University Computing Center         designed to inform the user what
Internet: <[e-mail]>       the weather is.
BITNET:   <LUKEN@LEHIIBM1>
=========================================================================
Date:         Tue, 26 Jul 88 12:18:44 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         [e-mail]
Subject:      request for opinions on future...
In-Reply-To:  <QUCDN.X400GATE:LR7X1Nmh*>

Believing all would-be virus writers have changed their ways is optimism
indeed. I just hope that someone is writing a super virus buster this summer
at the same time. Does anyone think this forum has helped/hindered the cause
of anti-viral warfare, or has it done nothing? Personally, I'm a LOT
smarter for having participated in this. Not that I was that smart to
begin with... (8*-)
=========================================================================
Date:         Tue, 26 Jul 88 18:11:00 -0500
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
Comments:     converted from NETDATA format at UOFMCC
From:         Steve Morrison <[e-mail]>
Subject:      request for opinions on future...
In-Reply-To:  <270*[e-mail]>

The scenario could be a mad-hacker, plugging away at a keyboard in
the back of a dimly lit office, creating a virus like no virus ever
seen before.  Viruses are going to be like methods of cheating at
cards or on your spouse.  The analogy would be having mice evolve
into a bigger species to defeat mouse traps - unless the traps are
built bigger, the mice will win.

Thoughts from someone who was out in sun today....
Devo_Stevo aka Stephen D. Morrison
[e-mail]
=========================================================================
Date:         Tue, 26 Jul 88 19:24:31 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         [e-mail]
Subject:      Rom Bios
In-Reply-To:  <QUCDN.X400GATE:LR4tF$bM*>

>Basically, Bios contains the routines that run all of your PC's I/O devices, i
n
>c
>luding
>the Monitor, and Disk Drives...
>
>DOS also supplies functions that do many of the same things.
>
So why is there this apparently redundant duplication of services in
the IBM PC world? Is this the case with other operating systems as well?
This seems to make (as has been pointed out before by others) DOS a really
leaky way of running a safe computing environment. Mind you, how could
the deveopers know that people would conceive of viruses?
=========================================================================
Date:         Tue, 26 Jul 88 11:16:00 PDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         [e-mail]
Subject:      Virus List

I'm a system programmer at a sight that supports probably 200 Macintoshes
of all types.  Is there a list of programs, both comercial and public domain,
that are known to contain viruses.

By the way, I'm new to my job and the idea of worying about viruses, so
if this a dumb question, please answer it anyway.

            Thanks,

                Stephen M. Youndt -- [e-mail]
                "Hacker at Large"

=========================================================================
Date:         Tue, 26 Jul 88 12:39:00 PDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         [e-mail]
Subject:      RE:      request for opinions on future...

One things for sure, open discussion has made virus writers either give
it up or become much more clever.  Let's hope the next generation of
information-immunologists are up to the task of combating the new viruses.


Stephen M. Youndt
"Hacker at Large"

(Not the bad type of Hacker)

=========================================================================
Date:         Tue, 26 Jul 88 12:01:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Shawn V. Hernan" <VALENTIN@PITTVMS>
Subject:      summertime virii


>As the virus world seems to have quieted down (at least here in the
>Academic community) over the summer, I'm interested to hear what people
>think will happen in the Fall and subsequent semesters as far as viruses
>are concerned.  Do you think that all the publicity has enticed some
>would be wrong doers into working on some super duper virus over the
>summer, only to be released upon their return to college?  Or is this
>too cynical an outlook?  Have we seen the end of viruses?  Perhaps all
>of the potential virus writers have decided to change their ways?  A
>lot of people who I've spoken with feel that a lot of virus writing
>efforts are taking place this summer; I hope that they're wrong.

>Opinions?

>Ken
__________________________________________________________________________
Speaking from the students point of view, I believe that if there are virus
writers working over the summer, they are not students. Several years ago,
this may have been the case. However, given the publicity that viruses have
received, it has become almost taboo among college students (at least the
sample I know). I believe college students in general lack sufficient
motivation to spend time writing a virus. There isn't any target (like a
government or rival corporation) as is the case with a small number of virii.
Also, there is a limited access to computers during summer for many students.
I believe if virii are being written, it is not by students, but by the more
educated (less responsible?) "adult" hackers with too much time on their hands.



                                                Shawn Hernan
                                                University of Pittsburgh
=========================================================================
Date:         Tue, 26 Jul 88 15:34:47 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Len Levine <[e-mail]>
Subject:      Re: request for opinions on future...
In-Reply-To:  Message from "[e-mail]" of Jul 26,
              88 at 12:18 (noon)

>
>Believing all would-be virus writers have changed their ways is optimism
>indeed. I just hope that someone is writing a super virus buster this summer
>at the same time. Does anyone think this forum has helped/hindered the cause
>of anti-viral warfare, or has it done nothing? Personally, I'm a LOT
>smarter for having participated in this. Not that I was that smart to
>begin with... (8*-)
>

I will be submitting a memo to the faculty here at UWM telling them
how to prepare for the inevitable virus attack.  I would like to
post it here tomorrow for suggestions and for you all to steal and
use if you would.


+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Leonard P. Levine                  e-mail [e-mail]    |
| Professor, Computer Science                Office [phone]    |
| University of Wisconsin-Milwaukee          Home   [phone]    |
| Milwaukee, WI 53201 U. S. A.               Modem  [phone]    |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

=========================================================================
Date:         Wed, 27 Jul 88 00:00:46 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         me! Jefferson Ogata <OGATA@UMDD>
Subject:      BIOSes and ROM BIOSes

Originally a BIOS was merely intended to abstract the hardware from the
operating system.  The BIOS would supply procedures for the operating
system that were independent of the hardware involved.  A case in point:
CP/M (again).

To have a CP/M machine, you need only supply about 30 different functions
in the BIOS.  These are primitive I/O functions such as console input,
disk seek, et alii.  The CP/M operating system itself is the same program
in all CP/M computers from Osbornes to Kaypros to Altairs.

As for the ROM aspect, it is just one way of handling the problem of
where to keep the BIOS.  Many CP/M computers keep the BIOS along with the
CP/M shell on a boot track on disk.  The whole shebang gets sucked in by
a boot program on powerup.  Others just keep the shell on disk and store
the BIOS in ROM onboard the computer.  The disadvantage of ROMing your
BIOS is that it becomes very difficult to alter it.  In my CP/M days I
found a number of hacks to my machine's BIOS that improved its perfor-
mance.  In addition, putting BIOS in ROM in a CP/M computer is of dubious
utility.  If there were any CP/M viruses, they would probably live
in the shell, not in the BIOS, which varies from machine to machine.

In the MSDOS case we have BIOSes in ROM consistently.  Many if not all
clones are designed to be hardware compatible with IBM PCs as far as is
possible.  Thus frequently the BIOSes are interchangeable.  But here my
knowledge of MSDOS is quite fuzzy.  But if clones had BIOS on disk, they
might be more susceptible to virus infection at the BIOS level.  Putting
the BIOS in ROM restricts infection to the operating system level.  I
seriously doubt IBM had this in mind when they designed it though.

Maybe someone with a good knowledge of the MSDOS details can provide
more specific information.

Happy trails,
- Jeff
=========================================================================
Date:         Wed, 27 Jul 88 07:51:19 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject:      Re: BIOSes and ROM BIOSes
In-Reply-To:  Message of Wed, 27 Jul 88 00:00:46 EDT from <OGATA@UMDD>


Jeff Ogata had a real good explanation for the ROM BIOS being the
intermediary between the operating system and the specific hardware.
In the CP/M world this was extremely important because hardware varied
from machine to machine, thus all standard CP/M programs used only the
operating system I/O facilities so that they could be sure to work
on any standard CP/M computer.  The end user need only supply his/her
terminal specific escape codes (clear screen, reverse video, etc.) to
install the program.  Then along came the IBM PC and hardware
compatability.  It didn't take long for the software developers to
realize that both the BIOS and the actual hardware *should* be the
same from machine to machine as long as it (the machine) is IBM PC
compatible.  By bypassing the MS-DOS (PC-DOS) I/O calls and going
straight to the BIOS or even the hardware, a middleman was eliminated,
and the resulting program worked a lot faster.  This practice also
weeded out the partially compatible machines rather quickly...

An anti-virus program can trap the operating system I/O calls (INT 21H)
very easily.  It's also rather easy to trap the BIOS routines in the same
manner.  It's not too simple to trap a program from working directly with
the computer's hardware (such as the hard disk controller).  And, since
the actual memory of the PC is alterable by any program (i.e., not
protected memory), it's real tough to assure that even any traps of the
operating system and BIOS remain intact.


Ken

Kenneth R. van Wyk                    From the Devil's Dictionary:
User Services Senior Consultant          Barometer - an ingenious device
Lehigh University Computing Center         designed to inform the user what
Internet: <[e-mail]>       the weather is.
BITNET:   <LUKEN@LEHIIBM1>
=========================================================================
Date:         Wed, 27 Jul 88 09:33:00 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         ACS045@GMUVAX
Subject:      reply to virus-l of 880727

>>As the virus world seems to have quieted down (at least here in the
>>Academic community) over the summer, I'm interested to hear what people
>>think will happen in the Fall and subsequent semesters as far as viruses
>>are concerned.  Do you think that all the publicity has enticed some
>>would be wrong doers into working on some super duper virus over the
>>summer, only to be released upon their return to college?  Or is this
>>too cynical an outlook?  Have we seen the end of viruses?  Perhaps all
>>of the potential virus writers have decided to change their ways?  A
>>lot of people who I've spoken with feel that a lot of virus writing
>>efforts are taking place this summer; I hope that they're wrong.

>>Opinions?

>>Ken
__________________________________________________________________________
>Speaking from the students point of view, I believe that if there are virus
>writers working over the summer, they are not students. Several years ago,
>this may have been the case. However, given the publicity that viruses have
>received, it has become almost taboo among college students (at least the
>sample I know). I believe college students in general lack sufficient
>motivation to spend time writing a virus.....
>
>                                                Shawn Hernan
>                                                University of Pittsburgh


Speak for yourself, but I feel that the worst has yet to come.  We have several
known hackers around here(banished from the system ages ago) who are probably
busily hacking away at the very such things you think college students are
beyond...In a sort of half-twisted way, I hope they succeed, it'll give us the
one final excuse the university needs to expel(sp?) them.
Plus, we are ready for them, I think.  After a terrible BRAIN attack in the
spring, our User Services and Support group mobilized, and everyone is quite
aware of viruses and the damage they can do.
Has this list been of any use??---yes, I myself know a hell of a *LOT* more
about virii than I did back in May, and I know it has helped wake up a lot of
people at both my jobs.
Thanks to all of you who have helped us separate the hype from the truth, and
what needs to/can be done about it all.

-------------------------------------------------------------------------------
Steve Okay
[e-mail]/[e-mail]/CSR032 on The Source
"Disclaimers???---We don' need no STEENKING disclaimers!!"

=========================================================================
Date:         Wed, 27 Jul 88 09:42:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         JJ_KRAME@FANDM
Subject:      Macvirus mailer

        I am preparing a disk/document mailing to all the departments
at my school. The topic on hand is viruses, specifically those
connected with the macintosh. There seems to be a lot of dis
information pertaining to viruses around the school, and I suppose
someone should set the record straight (or at least into a well-fitted
curve). The reason I am sending a letter to this mailer is to get feedback
on what I should include. I am including Apple's own virusRx, Thurman's
'Interferon', virus detective DA, and Vaccine. I need information to draw
from for the document I will be sending along. Any help would be
appreciated.   Joe Kramer

Consultant-- Franklin and Marshall College
Bitnet: JJ_kramer@Fandm
=========================================================================
Date:         Wed, 27 Jul 88 10:12:14 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         SHERK@UMDD
Subject:      Rom Bios
In-Reply-To:  Message received on Tue, 26 Jul 88  23:44:43 EDT

=========================================================================
>> Basically, Bios contains the routines that run all of your PC's I/O devices,
>>inclding th Monitor, and Disk Drives...
>>
>>DOS also supplies functions that do many of the same things.
>
>So why is there this apparently redundant duplication of services in
>the IBM PC world? Is this the case with other operating systems as well?
>This seems to make (as has been pointed out before by others) DOS a really
>leaky way of running a safe computing environment. Mind you, how could
>the deveopers know that people would conceive of viruses?

It isn't really a case of "duplication of services". One isn't supposed to
call the ROM Bios, instead you are supposed to call DOS which then calls
the ROM Bios. This serves to hide the implementation from the programer. The
advantage of this scheme is that radically different devices can be accessed
with the same logical DOS calls. The disadvantage is that it is slow...
=========================================================================
Date:         Wed, 27 Jul 88 09:57:53 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Joe McMahon <XRJDM@SCFVM>
Subject:      Re: Virus List
In-Reply-To:  Message of Tue, 26 Jul 88 11:16:00 PDT from <[e-mail]>

>I'm a system programmer at a sight that supports probably 200 Macintoshes
>of all types.  Is there a list of programs, both comercial and public domain,
>that are known to contain viruses.
Such a list would not help. Once you get one, you can pretty much bet that
everything else you've got has been hit, especially with the Scores virus.

>By the way, I'm new to my job and the idea of worying about viruses, so
>if this a dumb question, please answer it anyway.
No, it's not at all a dumb question. Mac viruses in general don't seem to
have been spread by Trojan programs, but by normally innocuous programs
which have become infected. The infamous infection of Aldus was supposedly
due to an infected copy of the program "Mr. Potato Head."  There have been
stories of late that infected copies of StuffIt have been uploaded (whether
maliciously or not, I can't say) to private bulletin boards.

PLEASE note that neither of these programs is a virus spreader! They are simply
victims of this plague.  I don't really know of any programs that are
specifically virus "vectors". YTou really have to be careful of everything you
get from anywhere other than the original author or an authorized distributor.
In fact, it's not a bad idea to run one of the anti-virals on those either.

If you need more information on Mac viruses and disinfection programs, order
the VIRUSREM PACKAGE from our LISTSERV here at SCFVM.  I'll be putting up a
documentation stack sometime soon (the next day or two, I hope).

--- Joe M.
=========================================================================
Date:         Wed, 27 Jul 88 11:31:56 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Joe Simpson <JS05STAF@MIAMIU>
Subject:      Re: Macvirus mailer
In-Reply-To:  Message of Wed, 27 Jul 88 09:42:00 EDT from <JJ_KRAME@FANDM>

I have used Apple's Rx and recommend it.  It not only looks for common
virus signatures in disk files, it will write what appears to be checksum
file for comparison at a later date. Rx does not prevent infection, it
looks for evidence of infection.

Vaccine appears to be reasonably efffective, but only if it is turned on
through the control panel.  Remember,  changes to the Vaccine control
check boxes only take effect upon reboot!  I don't use virusDective,
but it appears to work from the trivial testing I did.
=========================================================================
Date:         Wed, 27 Jul 88 11:55:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "David E. Spiro" <DSPIRO@BRANDEIS>
Subject:      Trapping Direct Disk Write Calls

>An anti-virus program can trap the operating system I/O calls (INT 21H)
>very easily.  It's also rather easy to trap the BIOS routines in the same
>manner.  It's not too simple to trap a program from working directly with
>the computer's hardware (such as the hard disk controller).  And, since
>the actual memory of the PC is alterable by any program (i.e., not
>protected memory), it's real tough to assure that even any traps of the
>operating system and BIOS remain intact.
>
>Kenneth R. van Wyk
>Lehigh University Computing Center

I remember reading in one of Peter Norton's books that he supports
programming that makes DOS (rather than BIOS) calls because then the
program should be more compatible with TSRs, window environments, etc.
Are there a lot of programs that ask for disk writes directly (i.e. not
through DOS)?  If not, would it be possible to write a TSR that
differentiates between disk write calls from DOS (making them legal) and
those that are direct (flagging them as suspicious)?

I'm not a programmer, so forgive me if this is gibberish.

David Spiro
Center for Interntional Affairs, Harvard University
Center for International and Comparative Studies, Brandeis University

DISCLAIMER: Blame it on my wife.
=========================================================================
Date:         Wed, 27 Jul 88 13:30:26 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject:      Re: Trapping Direct Disk Write Calls
In-Reply-To:  Message of Wed, 27 Jul 88 11:55:00 EDT from <DSPIRO@BRANDEIS>

>I remember reading in one of Peter Norton's books that he supports
>programming that makes DOS (rather than BIOS) calls because then the
>program should be more compatible with TSRs, window environments, etc.

True, from a standpoint of compatability, using DOS calls is much
better than bypassing DOS via the BIOS or the hardware.  It's also
probably a better programming practice (*OPINION*).  The only disadvantage
is that the DOS calls are horrendously (sp?) slow when compared to
the BIOS or hardware calls.  For example, writing characters directly
to video memory instead of using DOS INT 21 to draw them is at least
an order of magnitude faster (!), but won't work on all machines/display
adaptors.  The end-user will probably prefer the faster program (assuming
that it runs on his/her hardware) and it will probably sell better...

>Are there a lot of programs that ask for disk writes directly (i.e. not
>through DOS)?

Not too many bypass DOS on disk activity, but *most* bypass it for screen
I/O.  Many (all?) TSRs that do disk I/O bypass the DOS interrupts because,
being a single tasking operating system, DOS is non-reentrant.  This means
that no two pieces of code can (or at least *should) use the same interrupt
at the same time; so, if program X is doing an INT 21 when a TSR does an
INT 21, program X and/or the TSR will die a horrible death.  This doesn't
hold true for all DOS functions in INT 21, but at least for many of them.

>If not, would it be possible to write a TSR that
>differentiates between disk write calls from DOS (making them legal) and
>those that are direct (flagging them as suspicious)?

DOS itself must be able to do direct BIOS and/or hardware calls.  Like I
said, it is possible to trap the DOS I/O calls, so a TSR can look out for
them, and examine them to see if they're trying to do something nasty
(e.g., write to an executable file).  As far as I know, the closest
interrupt to the hardware disk I/O level is INT 13H; it, too, can be
trapped (it is in the BIOS).  Since it is in the BIOS, however, it must
be at an absolute memory location (in order for the machine to be truly
PC compatible), so any virus should know exactly where to find it in
such a way that cannot be trapped by merely stopping disk interrupts.
Perhaps there is a way to trap actual hardware level calls that I'm not
aware of...  Any ideas?  If virus Y sees that INT 13 is being grabbed by
another program, it's the easiest thing in the world (well almost...) to
reset the interrupt pointer to point straight to the BIOS in ROM, perform
the interrupt without fear of being watched, and restore the interrupt when
done (so as not to leave any traces) and continue.

Assuming that the interrupts remain unaltered, it is possible to examine
the interrupts return address to see whether it came from DOS or from
a user program/virus.  This assumes, also, that new versions of DOS use
the same locations in memory...  Sigh...

Hope this answers your questions...  Any other comments out there?

Ken


>
>I'm not a programmer, so forgive me if this is gibberish.
>
>David Spiro
>Center for Interntional Affairs, Harvard University
>Center for International and Comparative Studies, Brandeis University
>
>DISCLAIMER: Blame it on my wife.

Kenneth R. van Wyk                    From the Devil's Dictionary:
User Services Senior Consultant          Barometer - an ingenious device
Lehigh University Computing Center         designed to inform the user what
Internet: <[e-mail]>       the weather is.
BITNET:   <LUKEN@LEHIIBM1>
=========================================================================
Date:         Wed, 27 Jul 88 13:25:43 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Len Levine <[e-mail]>
Subject:      Re: Macvirus mailer
In-Reply-To:  Message from "[e-mail]" of Jul 27, 88 at 9:42 am

>
>        I am preparing a disk/document mailing to all the departments
>at my school. The topic on hand is viruses, specifically those
>connected with the macintosh. There seems to be a lot of dis
>information pertaining to viruses around the school, and I suppose
>someone should set the record straight (or at least into a well-fitted
>curve). The reason I am sending a letter to this mailer is to get feedback
>on what I should include. I am including Apple's own virusRx, Thurman's
>'Interferon', virus detective DA, and Vaccine. I need information to draw
>from for the document I will be sending along. Any help would be
>appreciated.   Joe Kramer
>
>Consultant-- Franklin and Marshall College
>Bitnet: JJ_kramer@Fandm
>

If and when you get it done, please publish it here.  I am sure that
lots of folks would be glad to steal/use with attribution the work
you have done. Thanks.


+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Leonard P. Levine                  e-mail [e-mail]    |
| Professor, Computer Science                Office [phone]    |
| University of Wisconsin-Milwaukee          Home   [phone]    |
| Milwaukee, WI 53201 U. S. A.               Modem  [phone]    |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

=========================================================================
Date:         Wed, 27 Jul 88 15:01:42 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         SHERK@UMDD
Subject:      Guarding against illegal DOS calls.

=========================================================================
>>An anti-virus program can trap the operating system I/O calls (INT 21H)
>>very easily.  It's also rather easy to trap the BIOS routines in the same
>>manner.  It's not too simple to trap a program from working directly with
>>the computer's hardware (such as the hard disk controller).  And, since
>>the actual memory of the PC is alterable by any program (i.e., not
>>protected memory), it's real tough to assure that even any traps of the
>>operating system and BIOS remain intact.
>
>I remember reading in one of Peter Norton's books that he supports
>programming that makes DOS (rather than BIOS) calls because then the
>program should be more compatible with TSRs, window environments, etc.
>Are there a lot of programs that ask for disk writes directly (i.e. not
>through DOS)?  If not, would it be possible to write a TSR that
>differentiates between disk write calls from DOS (making them legal) and
>those that are direct (flagging them as suspicious)?

When DOS is active, it sets a flag (in_dos). A simple TSR could trap all
ROM Bios calls and check the DOS flag. If the flag is set it could allow
the interupt and if the flag is not set it could return(error). Of
course it is easy to circumvent a scheme like this with a smart virus.

Erik Sherk
Workstation support staff - University of Maryland

=========================================================================
Date:         Wed, 27 Jul 88 16:15:45 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject:      Re: Guarding against illegal DOS calls.
In-Reply-To:  Message of Wed, 27 Jul 88 15:01:42 EDT from <SHERK@UMDD>

>When DOS is active, it sets a flag (in_dos). A simple TSR could trap all
>ROM Bios calls and check the DOS flag. If the flag is set it could allow
>the interupt and if the flag is not set it could return(error). Of
>course it is easy to circumvent a scheme like this with a smart virus.

Ok, then how about having the virus attach itself (i.e., rewrite) the
COPY command?  Simple, COPY is *allowed* to alter and move files, so
just "instruct" it to append a virus.  Obviously, this flag, in-dos,
would be TRUE if COPY is doing the work...  Oh, and COPY need only be
altered in memory, not on disk (in COMMAND.COM).  Just have, say, some
game alter it a bit.

>Erik Sherk
>Workstation support staff - University of Maryland

Ken

Kenneth R. van Wyk                    From the Devil's Dictionary:
User Services Senior Consultant          Barometer - an ingenious device
Lehigh University Computing Center         designed to inform the user what
Internet: <[e-mail]>       the weather is.
BITNET:   <LUKEN@LEHIIBM1>
=========================================================================
Date:         Wed, 27 Jul 88 13:55:29 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Len Levine <[e-mail]>
Subject:      Campus virus letter

To the group:

I plan to submit this for inclusion in an all campus newsletter
this fall.  The audience will be faculty and staff who are
reasonable, but do not understand computers or computering.

Any suggestions or advice would be appreciated.  Thanks.


+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Leonard P. Levine                  e-mail [e-mail]    |
| Professor, Computer Science                Office [phone]    |
| University of Wisconsin-Milwaukee          Home   [phone]    |
| Milwaukee, WI 53201 U. S. A.               Modem  [phone]    |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +


                 Potential virus Attacks at UWM

     UWM has a high probability of having its office PC's (so
called IBM compatible machines) struck with a computer virus
attack sometime soon, probably before June 1989.  If and when it
occurs, it is possible that nearly every office IBM compatible
machine will fail or lose files on the same day.  It will be a
very unpleasant time and our professional staff will be
overwhelmed by requests for help and will take some time (weeks)
to get the recovery process under way.  Most of us are unaware of
how dependent we have become on these desktop machines and how
much we will be affected by the loss of data that will ensue.

     Not only will the office machines be affected, but the home
machines that many faculty now have will also have their files
affected by the very same virus, and at the same time.  If you
are preparing a paper for publication, an exam, or some
correspondence, you may well find that your machine readable
copies of that material will become unusable both at home and at
the office.  This will be a very unpleasant experience.

     This paper discusses some evasive action that you can do now
to prepare for the return of your machine to working order.  What
I am recommending in this paper is no more than good housekeeping
and is practice that each of us should do anyhow, with or without
the threat of some mysterious computer virus.

     What I will discuss for the next few paragraphs applies to
users who have machines with either a floppy disk drive and a
hard disk drive or have two floppy disk drives on their
computers.

     Step one:  Locate the original source disks for the
           operating system you are now using on your computer.
           This may no longer be the system delivered with your
           machine, you may well have had an upgrade.  DO NOT PUT
           THESE DISKS INTO YOUR FLOPPY DRIVE YET.  Secure a few
           dozen write-lock tabs and put one on each of the
           delivery system disks.  (When you hold a disk upright
           the right side of the disk has a 1/4" square notch cut
           into the black paper jacket.  The write-lock tabs are
           black or aluminum colored gummed paper tags about 3/4"
           X 1/2" that can be stuck over the edge of the disk
           covering the front and back of this notch.  When that
           tab is in place it is not possible for the computer to
           write information onto a floppy disk.)

                Only after you have write-locked these disks
           should you put the disk into the computer and compare
           the system on that disk with the system you are using.
           STOP AND READ THE NEXT SENTENCE! The simple act of
           executing the DIR command on an unlocked disk is
           enough to infect that disk with a virus if your system
           is already infected and if the disk is not write-
           locked.  I am not kidding.  There is a very small
           probability that your system is already infected.  I
           recommend that you compare the date and size of the
           file COMMAND.COM on your original source disks and on
           your working disk or disks to see that they are the
           same.  For my system the results look like this:


              C> dir a:\command.com

               Volume in drive A is MS330PP01
               Directory of  A:\

              COMMAND  COM    25276   7-24-87  12:00a
                      1 File(s)      5120 bytes free

              C> dir c:\command.com

               Volume in drive C has no label
               Directory of  C:\

              COMMAND  COM    25276   7-24-87  12:00a
                      1 File(s)   7391232 bytes free


           Note that both copies of COMMAND.COM have the same
           date and time of creation (midnight on July 24th 1987)
           and both are the same size (25,276 bytes).  The
           numbers for your machine may well differ from mine,
           but both should be the same.  When those disks have
           been found, put them away in a safe place.  I
           recommend that they be put in a plastic storage box
           not too near your computer.

     Step two:  There are a small number of software packages
           that you would be lost without.  In my case they
           include WordStar, dBase III, PKARC, Kermit, and
           Directory Scanner.  These packages may well be
           purchased commercial software (WordStar, dBase III),
           shareware (PKARC, Directory Scanner), and freeware
           (Kermit).  In each case you should have an original
           source delivery disk for each of these packages.  Find
           those disks, WRITE LOCK THEM, compare them with the
           copies you are now using, and put them in a save
           place.  I recommend that they be put with the system
           disks discussed above.  (It is probably true that the
           creation dates for the running copies of this sort of
           software will disagree with the creation dates for the
           delivery disks.  Installation of many of these
           packages entails writing to the program.  That is not
           a problem.)

     Step three: Using the backup procedure of your choice,
           perform a backup of the system files on your computer.
           If I was using a dual floppy based system, I would
           simply make copies of my working WordStar, dBase III,
           PKARC, Kermit, and Directory Scanner disks.  If I was
           using a computer with a floppy and a hard disk, I
           would use backup-restore, or Fastback or some other
           package to back up the directories C:\WS, C:\DB3,
           C:\ARK, C:\KERMIT and C:\DS.  (Of course these
           directories have different names on your system.)
           Write lock these backup disks.  Label them with
           today's date.  Using your backup system compare the
           disks you have just backed up with the disks you are
           using to ensure that the backup "took".  Put the
           backup disks in a safe place.  This will tie up half a
           dozen disks, but with disks now costing $0.35 each,
           you will probably find the $2 investment worth while.

     Step four:  (This applies to those users who hard disk based
           computers.)  Prepare a backup procedure that will
           permit incremental backups.  This will entail backing
           up the entire system once, and then periodically
           backing up those files that have changed since the
           last backup.

           Perform such incremental backups regularly.  After
           several such incremental backups, the size of the
           backup set will become quite large.  At that time, put
           the backup set away in a safe place and begin with
           another set of disks for a full system backup followed
           by several increments.  When the second set is full,
           put them away and return to the first set.  This will
           afford a very secure set of backup files.  I find that
           50 disks makes a good backup set.  Thus 100 disks
           would be used for the double backup group.  I suspect
           that most users would need to do a full backup about 4
           to 8 times per year, requiring about 1/2 hour of
           manipulation and should do incremental backups about
           twice per week, requiring less than 5 minutes.

           (It is a very good idea to periodically test the
           backup system with a verification of what you have
           backed up.  Most file backup systems have a Verify
           command to do this sort of test.)

     Step five:  Go back to your useful work.

     Recovery from the lost of one or a few files:

     Sooner or later you will lose some files.  They will
dissapear without apparent cause and you will blame the problem
on a virus.  It is my experience that no virus is involved, the
loss of files will be due to an operator error.  If you have been
doing incremental backups, then the simplest corrective action is
to use the recover feature of the backup system that you are
using and simply restore the latest copy of the lost file(s) to
the hard disk.  If you have been consciencious then the loss of
work will entail just a few minutes or hours of rework.

     Recovery from the loss of the entire system:

     It may happen that the entire hard disk seems to be lost.
This is serious and is most likely not the result of a virus.
Most failures of the hard disk are due to hardware problems.  The
best solution is to repair the hardware if the technical people
judge that that is the problem, and then, after reformatting the
hard disk, restore the system from your latest backup.  Almost
without fail, this will result in a complete return to a normal
system.

     Really bad news, the restore does not work:

     This may well be the point of this memo.  If a virus has
been planted in your system and has been set to trigger on some
event, then the only way to recover is to rebuild the system from
scratch using the write locked set of disks that I advised you to
prepare above.  If these disks are not write locked, and if you
mount them onto an infected system, then the disks will be
infected in turn and you may well be unable to restore from a
clean, uninfected source.  On the assumption that you can build
your system again from scratch, you may restore all of the data
files from your backup set.  (A data file is one that does not
have the extension .com, .exe, or .sys.)  Any other file should
not be able to carry a virus either between systems or over the
backup process.

     Some facts:

     There is no reason ever to boot the system from a foreign
disk.

     There is no reason why a disk used to transport data between
manchines should have a copy of the files io.sys, msdos.sys,
ibmio.sys, ibmdos.sys or command.com on it.

     No system to date has been infected by the transport to it
of data files.  Only executable files can be used as trojan
horses.



+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Leonard P. Levine                  e-mail [e-mail]    |
| Professor, Computer Science                Office [phone]    |
| University of Wisconsin-Milwaukee          Home   [phone]    |
| Milwaukee, WI 53201 U. S. A.               Modem  [phone]    |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +

Thanks.

L. P. L.

7/27/88



=========================================================================
Date:         Wed, 27 Jul 88 19:54:00 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Robert Adsett <SEMICON@WATSCI>
Subject:      RE: Re: Trapping Direct Disk Write Calls

>Perhaps there is a way to trap actual hardware level calls that I'm not
>aware of...  Any ideas?  If virus Y sees that INT 13 is being grabbed by
>another program, it's the easiest thing in the world (well almost...) to
>reset the interrupt pointer to point straight to the BIOS in ROM, perform
>the interrupt without fear of being watched, and restore the interrupt when
>done (so as not to leave any traces) and continue.

   Actually it's easier than that.  All the program has to do is set up the
stack properly and do a direct jump.  Of course this assumes that the location
of the interupt in the bios and so will not work with all bios's.
I don't know of any way to trap this.

                Robert Adsett   <[e-mail]>
                                <[e-mail]>
                Dept. of Phys.
                Univ. of Waterloo
                Waterloo Ont. Canada


" 'Freedom' has no meaning of itself.  There are always restrictions,
be they legal, genetic, or physical.  If you don't believe me, try to
chew a radio signal. "

                        Kelvin Throop, III

=========================================================================
Date:         Wed, 27 Jul 88 20:33:47 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         SHERK@UMDD
Subject:      Re: Guarding against illegal DOS calls.
In-Reply-To:  Message received on Wed, 27 Jul 88  17:56:39 EDT

=========================================================================

!When DOS is active, it sets a flag (in_dos). A simple TSR could trap all
!ROM Bios calls and check the DOS flag. If the flag is set it could allow
!the interupt and if the flag is not set it could return(error). Of
!course it is easy to circumvent a scheme like this with a smart virus.

>Ok, then how about having the virus attach itself (i.e., rewrite) the
>COPY command?  Simple, COPY is *allowed* to alter and move files, so
>just "instruct" it to append a virus.  Obviously, this flag, in-dos,
>would be TRUE if COPY is doing the work...  Oh, and COPY need only be
>altered in memory, not on disk (in COMMAND.COM).  Just have, say, some
>game alter it a bit.


>Ken

>Kenneth R. van Wyk                    From the Devil's Dictionary:

A virus that is smart enough to hack the resident portion of command.com
would probably know about IN_DOS. The TSR scheme I proposed offers a
low-level of protection, no much above write protecting your disks. The
advantages of it are that it can be kept active all the time with little
performance degradation.

Erik Sherk
=========================================================================
Date:         Thu, 28 Jul 88 12:22:55 GMT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Turgut Kalfaoglu <TURGUT@TREARN>
Subject:      Re: ROM Bios
In-Reply-To:  Message of Mon,
              25 Jul 88 17:54:59 EDT from <[e-mail]>


>What is ROM Bios? What are legitimate reasons for a program using it/them?
>What are illegitimate reasons for the same? Enquiring minds want to know...

ROM bios is basically a whole slew of routines that are coded into a chip.
They provide all kinds of functions from keyboard, to screen, to disk.

BIOS calls, like the ones for the screen, tend to be faster than their
counterparts in DOS calls, but your program will only run with a system that
has ROM bios.

ROM BIOS is also usually the cause for 'incompatible compatible
computers.' - since IBM's BIOS chip is (C)opyrighted, and cannot be used by
other companies freely. Many companies have developped their own chips to
provide similar functions. I hear that the Phoenix BIOS is the most compatible,
and that the Award BIOS is another popular one..

Legitimate/Illegitimate: I dunno.. You can use BIOS to write directly to a
sector on disk, so a virus could use it to destroy something, or to write
itself onto a fresh disk.. Maybe that's what you mean by leg/illeg...

-turgut
=========================================================================
Date:         Thu, 28 Jul 88 15:20:35 GMT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Turgut Kalfaoglu (51)18-10-80 Ext:244" <TURGUT@TREARN>

Here in Izmir, Turkey, we have a BRAIN version 9.0 on our PC lab.
We are trying to get more info on it, and trying to analize its
behavior. So far, it doesn't seem to like hard drives - we have
not been able to locate one on a hard drive.

It jumps from diskette to diskette easily, by simply writing itself
to the boot track of the new diskette. We found that the best way to
find this virus is to look at the FIRST track of the diskette. It has
a message there. We use Norton or PCTOOLS to peek at that sector.
We are also working on a program that verifies that track, and the
checksums/crc's of the three system files..

I think the computer centers/BBS's, and other similar services should
record the sources of the obtained software.. This would intimidate
the creep (the virus-writer) on distributing the virus-installing
software..

-turgut
=========================================================================
Date:         Thu, 28 Jul 88 09:34:47 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "James N.Bradley" <ACSH@UHUPVM1>
Subject:      Re: Campus virus letter
In-Reply-To:  Your message of Wed, 27 Jul 88 13:55:29 CDT

Leonard -

I edit the computing center publications at the University of Houston and
we couldn't publish your article as it stands.  The use of words like
"high probability", virus "attack", and "evasive action" is inflammatory.
These words are not going to provoke reasonable reactions from people.
You have to be very careful when using powerful and sweeping statements.

A better way of beginning your paper would be something like:

Some campuses have had problems recently with virus program.  A virus program
is (etc).  There are a number of things you can do to prevent infection...etc
If you become infected there are a few things you can do...etc

Tone down the dire images unless you know you have a virus on campus.


James N. Bradley
Information Services Manager
University of Houston
=========================================================================
Date:         Thu, 28 Jul 88 09:48:11 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         GARY SAMEK <C133GES@UTARLVM1>
Subject:      Re: Trapping Direct Disk Write Calls
In-Reply-To:  Message of Wed, 27 Jul 88 13:30:26 EDT from <LUKEN@LEHIIBM1>

Hello Net,
  When a virus gets into command.com, it is very difficult to stop it from
spreading if it is well written.  It seems that the best way to prevent
this type of virus is to keep an eye on the dates on these files.  Then,
you would probably want a TSR to notify you whenever a DOS/BIOS call to
change the date of a file has been requested.  This would require a little
more attention of the user, but the protection scheme is simpler and fairly
reliable.
  Upon thinking, it would probably be a good idea to keep the output of the
DIR command as a disk file, so you could check from time to time, the sizes
of the files as they were and as they are now.
  Anyway, I would like to see a little discussion on a good generic technique
on preventing the infection and spread of virus, such as I have given here.

Gary
Disclaimer - These opinions are my own, and whoever else agrees.
=========================================================================
Date:         Thu, 28 Jul 88 11:23:01 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         OJA@NCCIBM1

Re: Ken's request for opinions about future virus activity / and
    "warning lists" about Trojan Horses and viruses

"All the data is not yet in" for the question of future virus activity,
but here is my opinion from this vantage point....

Several trends are developing, making the situation a "good news and
bad news" one. The good news is that it looks like virus attacks on
consumer/hobbyist/small instituation computers is leveling off and
will most likely drop, with occaisionally outbreaks. One factor for this
is that the "fad" is wearing off for those who write viruses for the
"thrill". The other, more significant, reason is that many computerists
are becoming much more computer security conscious than ever before.
he number of files being transfered an many BBS's that I am on has
dropped greatly in the past six months. People are getting more careful,
slowing the spread of malicious codes.Many have started using some
form of general protective/testing software. (No, they are no absolute
garauntees, but it is step up from indiscrimate software exchange.)

The degree of complexity and sophistication to make a "successfull"
(from the perpetrator's viewpoint) virus is being driven upwards.
The bad news is the possibilty of specifically targetted virus will
increase as various people are seeing the potentials and dangers of
this electronic parallel to nanotechnology. This is a concern that the
institutions that would be possible targets are already building more
secure systems. There is possibility of "spillovers" to the general
computing community from any attempted attackes. (In the case of
targetted attacks, the result does not need to destroyed files, wrecked
boot sectors, and other obvious damage. A subtle data manipultor could
do much damage. But enough said for here.) So many institutional
computer centers are wise in constantly looking to secure their systems.

 A related factor in these trends is the matter of accountability
and other human factors. Few months ago, Vin McLennen had posted a
report in RISKS DIGEST about the various problems with employee
accountability in the computer and data management field. This seems to
intensified after the US Stock Market plunge last fall; the message
given to employees by many companies after thatwas "Produce bottom-
line profits or you're out!" (I have seen this message in some of the
advertising in computer & telecommunications publications- the appeal
to fear.) Even before the virusese, one of the biggest security
problems for a company has been disgruntled employees.

On a different subject.....
Somebody posted a request on this list for information about any
"warning lists" of Trojan Horses and viruses. The only one that I
know of is the DIRTY DOZEN listing compiled by Eric Newhouse. It is
available through LISTSERV@LEHIIBM1 as DIRTY DOZEN. Use the GET
command to get it. The latest version is 8b. Eric says that he
will coming out will version 9 soon. He will be splitting it up into
separate listings for Trojan Horses, Viruses, Pirated and Hacked
Programs, etc. The DIRTY DOZEN listings can be obtained also from
Eric's BBS - THE CREST BBS in Los Angeles, CA - [phone].
There is also a message section on the CREST BBS for messages about
any newly discovered "bogusware".If neither routes are practical,
contact me and I can arrange for a copy (disk or printout) to be
sent to interested people by arrangement.

J. D. Abolins
301 N. Harrison Str., #197 /Princeton, NJ 08540  (mail only)
=========================================================================
Date:         Thu, 28 Jul 88 11:24:22 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject:      Re: Trapping Direct Disk Write Calls
In-Reply-To:  Message of Thu, 28 Jul 88 09:48:11 CDT from <C133GES@UTARLVM1>

>It seems that the best way to prevent
>this type of virus is to keep an eye on the dates on these files.

Not at all true; it's all too simple to alter a file without altering the
date.  *DO NOT* trust the write date as a virus detection scheme.

>This would require a little
>more attention of the user, but the protection scheme is simpler and fairly
>reliable.

It would be simpler alright, but also much simpler to get around.

>  Upon thinking, it would probably be a good idea to keep the output of the
>DIR command as a disk file, so you could check from time to time, the sizes
>of the files as they were and as they are now.

It's also easy to alter a file without changing the file size as well.
Particularly in the case of COMMAND.COM, the code need not even be
altered on disk at all - it need only be altered within memory, and
that can be done by any program at all since a PC's memory is totally
unprotected.  Once again, a file can contain a virus without any file
size or write date change from the original (uninfected) file.

>Gary

Ken

Kenneth R. van Wyk                    From the Devil's Dictionary:
User Services Senior Consultant          Barometer - an ingenious device
Lehigh University Computing Center         designed to inform the user what
Internet: <[e-mail]>       the weather is.
BITNET:   <LUKEN@LEHIIBM1>
=========================================================================
Date:         Thu, 28 Jul 88 17:05:54 GMT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Turgut Kalfaoglu <TURGUT@TREARN>
Subject:      Re: Trapping Direct Disk Write Calls
In-Reply-To:  Message of Wed, 27 Jul 88 11:55:00 EDT from <DSPIRO@BRANDEIS>


>Are there a lot of programs that ask for disk writes directly (i.e. not
>through DOS)?  If not, would it be possible to write a TSR that
>differentiates between disk write calls from DOS (making them legal) and
>those that are direct (flagging them as suspicious)?

Yes, there are many programs that write to screen. Most programs that 'pop'
into view are either writing directly to screen, or using a technique
called 'page flipping' - which is similar to turning the pages of a book.
(Prepare the next page, then flip the pages)

For an example of the difference in performance, try invoking the Norton
Utilities with the /D1 option or the /D2 option. (Which I believe are BIOS and
DOS calls with ANSI, respectively)

Trapping such calls would be difficult - you would have to check for every
memory access (there are LOTS of them), to see if they fall within a
device's area. For example, to write to screen, you simply send a byte
to a location in memory, and the character appears..
-turgut
=========================================================================
Date:         Thu, 28 Jul 88 11:58:24 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Loren K Keim   -- Lehigh University <LKK0@LEHIGH>

A few brief comments on recent activity on this list:

Turgut:  There are quite a few Brain variations foloating around
at this particular moment.  We have counted 7.  The original
Brain Virus ONLY effected floppy 5 1/4 inch disks.  And it did
no harm.  Versions are around that effect hard disks and 3 1/2
inch disks, but they are simply edits of the original.  Also
damaging versions exixst.  One will periodically delete files,
the c second will erase your FAST table.  (please excuse my
typeing, I have no backspace).  That should read FAT table.
I have now worked on two versions of the Brain virus and
am looking for the others.  Also, I am curious to nknow who
was the first college to dicscover the Brain.  I really
don't know who isn the US was hit first.

Gary:  Watching the Dates change means mnothing.  It is a
very simple function to keep the date from changing.  The
date change was one of the major reasons we caught the Lehigh
Virus in the first place.  If it hadn't changed, Chris, Joe
and I and Mitch probably wouldn't have realized what was
going on for a qhile after that.  Whoever wrote the Lehigh
Virus made a mistake, and I think any new viruses that crop
up will not make that same mistake.

JD:  I have been trying to compiler a list of viruses.  This
is very difficult.  I have sent mail out to just about everyone
and no one is keeping one.  We have ome across about 70 viruses
now including 4 versions of the Israeli and 7 versions of the
Brain.  If anyone wants to make a short list of the ones they
know3 of, please send it to LKK0@LEHIIBM1 and I will include
them in my compilerd list.  I will post it when I feel it is
sufficeintly done.

Virus Growth:   I expect a virus explosion of GOOD virues on
campuses next year.  A bank in upper New Jersey (who I am
not allowed to mention othe name otf) called me about 3 weeks
ago.  They were hit pretty basdly by a virus.  I honesty see
viruses increasing in hostility and in design.

The problem is that theyre is so much publicity about viruses
right now that we can't handle the problems cropping up.
Another problem I will hate to see, but it looks like it is
coming is a virus that runs on PC's and attacheds itself to
mainframes when the PC conects to them.  It will themn "worm"
its way through the mainframes.  We've been doing research on
this type of virus for a while, and a small one was located
in Harrisburg I'm told.  I cannot describe it I'm osorry to
say.  Evey time we do something, we're told to keep quite and
not fuel the scare.

About not being able to trap diredct disk writes without
trapping DOS calls.  OUr package ,... first let me say that
I am NOT trying to sell it over Bitnet, I just want to
point out that our package from Lehigh Valley Innovative
Technologies, does just that.  And it does it well.  We
do trap disk calls and check to see whether they came from
DOS or directly from the program.  And believe me, it
works, and it would be very hard for someone to mess with
it, unless they want ot disassemble all our code and try
to figure out how everything works.

One other thing:  James Bradley, your english is much mbetter
than mine, but I'm afraid there is a VERY high probablyility
of ANY college with PC sites to be hit by a virus.  Protect
yourselves NOW!

Loren Keim
Lehigh University Provost Staff
=========================================================================
Date:         Thu, 28 Jul 88 09:30:31 pdt
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         isbalkits@UCDAVIS

Devo_Stevo writes:

        "The scenario could be a mad-hacker, plugging away at a
        keyboard in the back of a dimly lit office, creating a
        virus like no virus ever seen before.  Viruses are going
        to be like methods of cheating at cards or on your spouse.
        The analogy would be having mice evolve into a bigger
        species to defeat mouse traps - unless the traps are
        built bigger, the mice will win."

Depicting the virus writer as a gothic/romantic figure (like pirates
have been, like gangsters have been, like gang members now are)
contributes to the problem.  If this discussion is to have any value,
any impact, it should be to paint the virus writer as he/she truly
is: an emotionally-atrophied individual, a product of negative
operant conditioning, a human who has lost contact, isolated in a
hyperspace of computer an-architecture, where techical wizardry
seems to excuse a lack of  common ethics or even common sense.

Continuing to fictionalize the virus writer as a mad scientist, a
Doctor Frankenstein whose genius gives us a secret thrill, whose
lawlessness challenges us, is just the wrong way to go.  If this
forum really exists as a deterrent to the spread of viruses, one
of its functions is the demystification of the criminal hacker.
Calling her/him a "creep" is not enough.  The consciousness in
each of us should be raised that we are contributing to the virus
writer's self-image as someone "special" whenever we present the
problem in adventurous scenerios such as that above.

Ivars Balkits
Computing Services
University of California - Davis
ISBALKITS@UCDAVIS
=========================================================================
Date:         Thu, 28 Jul 88 12:42:15 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "David M. Chess 862-2245" <CHESS@YKTVMV>
Subject:      How many viruses are there?

Loren K Keim writes
> There are quite a few Brain variations foloating around
> at this particular moment.  We have counted 7.
 ...
> I have now worked on two versions of the Brain virus and
> am looking for the others.

Does that mean that you've counted 7 rumors, but only really
seen two different versions, or that you have good, solid
evidence of seven versions, but for some reason only have
copies of two?  I've seen two versions of the Brain virus
(both attack only floppies, and in fact the only difference
between them is in the no-op data areas), and heard rumors
of lots of others.   In every case, though, the rumors seem
to have been due to mistakes or confusions, and I wouldn't
be at all surprised if there are in fact only two versions
out in the world.   If you have hard (first-hand) evidence
of others, I think we'd all be interested.

I have good evidence for only 6 (or 7) viruses for PC-DOS
in actual circulation: the Lehigh, the Jerusalem, two
"April Fools" viruses which have already passed their
setoff dates, the Brain (and its minor variant), and a
small COM-file virus that occasionally replaces its
victim with a program to reboot the machine (rather than
simply infecting it).

Anyone who knows first-hand (or from a solid non-rumor source)
of more viruses would be doing everyone a great service by
posting a detailed description of their symptoms, so we can
all tell our users about things to watch out for.  (Loren, if
any of the seven that I mentioned above are new to you, let
me know and I can send you more details; I'd love to see that
list of 40, especially if it includes some hint of how sure
we really are that each one exists!)

All this is not to say that viruses aren't something to worry
about!   Quite the contrary.   But I do tend to think that new
rumors tend to appear MUCH faster than new viruses do...

DC
=========================================================================
Date:         Thu, 28 Jul 88 13:58:05 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Loren K Keim   -- Lehigh University <LKK0@LEHIGH>

Dave:  About rumors versus real versions, I have heard rumors
about so many versions of the Brain that it isn't funny.  Fred
Cohen described the Brain found in Mimi as a varient strain
and whent on to explain it.  It sould... sounded exactly like
the original to me.

I have heard of 7 versions from reliable sources.  Unfortunately
most people won't allow me to have copies of their viruses.
The two I have are from California and Boston.  People are so
afraid of virusses that I am ahaving difficult getting ahold
of some strains.  I have to get permission sent from the
government to these poeple fro them to release copies to me,
that is why I only have 2.  Its kind of interesting that
I travel places to help stop viruses but I can't get ahold
of some copies because people don't ... no one trust s anyone
else.

I have either copies or f or heard from reliable sources of
4 Aporil Fool's fviruses, 7 versions of the Brain, the Lehigh,
4 versions of the Israeli (there are early versions floating
around Hebrew U I'm told, bpresumably written by the culprit
who wrote the Istraeli), the Playboy, the Brain.. Gerbil I'
mean, and some minor ones (I' do not have a list in front of
me, this is from memory).  For the Mac, I've seen aa version
of the CHRISTA virus (yes, simple damn thing copies itself
around your little Mac, its not written in Rex of course),
the Phantom, the NASA virus, the Aldus virus, and the VULT
virus.  The Flushot renegade for the PC was something i
should also point out.  The CHRISTMA for the CMS machines,
a Smiley face virus which was the Chrisma redone .
4 unnamed Unix viruses and I have rumors of more floating
around.  (one of them is onely a few characters long and is
very ansty).  That is the start of a list.. oh, yeah, another
off the top of may head is a Mac virus which prints a picture
of a nude female on the screen while it copies itself to any
other disks in your system.  And obvious virus but still
a virus.  I have heard rumors of a similar virus for the PC.

Loren Keim
Lehigh University
=========================================================================
Date:         Thu, 28 Jul 88 14:14:37 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Loren K Keim   -- Lehigh University <LKK0@LEHIGH>
Subject:      Questions about Brain

Actualy, I've been trying to tarack the Brain Virus for some
time.  If anyone out there has had any contact with the
Brain virus, I would really appreciate some info from you
(dates, what it did, what it looks like, how it worked, when
it hit, how many people it effected and so on).

Also, does anyone know if any research has been done on Worm
Theory since the big Xerox worm back in 82?

Does anyone have a copy of the Apple version of Core Wars?

Does anyone know where Len Adleman is now?  (He's the person
who first called a computer virus an coputer virus.  (if my
typing were better)

Is it true that University of Penn found a Command Com virus?

I'd like to know who all was hit the worst by the Christas
Tree Exec.

How far did the Aldus virus get?

Can anyone tell me about the NASA virus other than what was in
the papers?  (NASA claims they didn't have a virus!)

Is nanyone planning on teachine a virus course in the future?
Which colleges teach computer security.

Loren
=========================================================================
Date:         Thu, 28 Jul 88 14:32:10 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "David M. Chess 862-2245" <CHESS@YKTVMV>
Subject:      How many viruses are there?

The only "Playboy" thing that I've heard of reliably was just a
Trojan Horse for the Mac, not a virus for the IBM-PC or compatibles.
Similar comment applies to the corrupted flushot thing, I think;
it just did nasty things to you when you ran it, but it didn't
spread itself to other executables.   A list of Trojan Horses
would be miles long, but not really relevant to the subject matter
of VIRUS-L.   I suspect a list of real viruses would be much
much shorter.

DC
=========================================================================
Date:         Thu, 28 Jul 88 14:41:49 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Joe McMahon <XRJDM@SCFVM>
In-Reply-To:  Message of Thu, 28 Jul 88 09:30:31 pdt from <isbalkits@UCDAVIS>

>Continuing to fictionalize the virus writer as a mad scientist, a
>Doctor Frankenstein whose genius gives us a secret thrill, whose
>lawlessness challenges us, is just the wrong way to go...

I agree. I find virus writers just about as romantic as a sniper on the
freeway. "Oh look, I just killed somebody else." Too bad brainwashing is
illegal (don't flame - I'm being VERY sarcastic).

--- Joe.
=========================================================================
Date:         Thu, 28 Jul 88 13:59:24 CDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Len Levine <[e-mail]>
Subject:      Re: Trapping Direct Disk Write Calls
In-Reply-To:  Message from "Kenneth R. van Wyk" of Jul 28, 88 at 11:24 am

>It's also easy to alter a file without changing the file size as well.
>Particularly in the case of COMMAND.COM, the code need not even be
>altered on disk at all - it need only be altered within memory, and
>that can be done by any program at all since a PC's memory is totally
>unprotected.  Once again, a file can contain a virus without any file
>size or write date change from the original (uninfected) file.

Very interesting about command.com.  That file, as released in
msdos level 3.3 contains a 4000 byte block of zeros at its end, which
makes it VERY easy to add code.

I cannot fathom why they put that area into the process.


+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +
| Leonard P. Levine                  e-mail [e-mail]    |
| Professor, Computer Science                Office [phone]    |
| University of Wisconsin-Milwaukee          Home   [phone]    |
| Milwaukee, WI 53201 U. S. A.               Modem  [phone]    |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +


=========================================================================
Date:         Thu, 28 Jul 88 14:33:14 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Neil Goldman <NG44SPEL@MIAMIU>

Virus prevention programs (those which claim to stop infection *before* it
occurs) typically intercept calls to the DOS (or BIOS) interrupt handlers.
If the interrupt request is to write to the disk, the prevention program will
notify the user.  The general impression I get is that people think that if
a program can intercept all potential avenues a virus can take to write to the
disk, it would be foolproof (or close to it).

However, a clever virus could simply check to see if the interrupt vector
is pointing to something other than the DOS/BIOS commands to write to the disk
(i.e., the vector would point to the intercepting prevention program).  If the
virus determines that the vector does not point to DOS/BIOS, it could simply
change the vector to do so, replicate itself (infect other programs), and then
change the vector pointer back to the "intercepting program".  The user would
be none the wiser.

Comments/technical corrections?


Neil A. Goldman
Ernst & Whinney
National Computer Audit Group
=========================================================================
Date:         Thu, 28 Jul 88 14:08:50 CST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Claudia Lynch <AS04@UNTVM1>
Subject:      Possible Virus


The following message appeared on our campus BBS. If anyone has any
pertinent information, please reply.

Thanks,

Claudia Lynch We shall work no time, before its nine!|


#1791  28-JUL-1988 08:57:33.73    Topic : PUBLIC INFO
From : ALAN MATTHEWS
To : ALL
Subject : possible virus

I've been using the "Master Key" utility by R.P.Gage. For a while and have
been having problems with my disk. It is a really nice utility program; it
allows you to hide,unhide,delete,and undelete files, look for matching
files , and has a hex/ascii sector editor(that's the best way I can
describe it)  I had, until recently been blowing my FATS sectors. This
caused my endless amounts of annoyance as I would get parity errors on my
disk drives, and eventually would not be able to load programs. I finally
erplaced my motherboard and these problems haven't surfaced again(yet).
 I'd like to know if anyone has had similar prioblems with this program,
or if it was, in fact, just a hardware problem.
AM
=========================================================================
Date:         Thu, 28 Jul 88 15:49:44 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Loren K Keim   -- Lehigh University <LKK0@LEHIGH>

David,

When I speak of the Playboy virus, I am referring to one of
the many things by that name.  I refere to a POC program which
was complained about slightly in Main I brelieve tha simply
copies itself from disk to disk.  It is an executable fiel
that does this.

I should not have nmentioned the Flushot thing, I know it is
a trojan.   When I talk of a certain number of viruses, I
ONLY mean viruses.  A list of trojan horses would come out
with at least several hundred.  However, I am counting
variations of viruses as viruses themselves.  In my posession
I have about 15 viruses and about 20 trojan horses, I have
a list of about 70 viruses from reliable sources.  I also
do not include viruses that peop-le wrote themselves to
annoy their co-workers.

Haggling oover the specifc number of viruses in the world,
however is rediculous.  Incdidently, I received two boot
sector viruses in the mail (physical mail) without a
return address, and they are viruses I cannot identify as
anything in particuloar.

Also, is anyone on this list from Alabama or Mississipi?

Loren
=========================================================================
Date:         Thu, 28 Jul 88 15:59:51 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Loren K Keim   -- Lehigh University <LKK0@LEHIGH>

Regarding anti-viral programs, I don't think anyof them is
the answer.  I'm leaning towards hardware protections, and
have a few ideas.  We really need the hardware to be resdesigned.

There isn't anything we can do to prevent the pspread of virueses.
All we can do is make it harder and harder for one to get
around.

Neil, if you were referring to my comments arbout the program
we've written, we considered what to referred to as taking
over the interrupts, but its too shabby a job and isn't the
way we do it.  We also, of course, watch for interrupt changes.
But again this is not the answer to all our problems.

Fred Cohen demonstrated up in New York a little probgram which
basically CRC'd everything (it was a powerful check, but still
just a file check).   And I think that isn't enough either,
our program has more than just disk watches, it has the standard
CRC's for people who want to use them (one-way increyption) and
so on.

If enough people use Vaccine and the Innoculator and SDP, and
FluShot, then a virus really doesn't stand a chance of getting
too far.  The more packages out there, the harder a virus
is to propogate.  Antoher point, something Fred's program
does, Vaccine does and our does is have a random key selected
which keeps the virus vfrom being able to mimic any CRC.

The only thing we can do is make it harder and harder to
write a virus which will go through our derfenses, and limit
the number of people who CAN write one.

Fred, incidently, talked of making the nth level of difficulty
in writing a virus, in which case we are safe.  I thinkk the
world is on the right track.  Now we have to convince the
world to use the PC condoms that exist (not necessarily anyone's
ion particular).

Loren
=========================================================================
Date:         Thu, 28 Jul 88 16:07:35 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Loren K Keim   -- Lehigh University <LKK0@LEHIGH>

(Heavy mail is BACK on Virus-L!)

One more thing Neil,

We're more and more referring to Anti-Viral programs as
"Virus Detection Systems" not "Virus Prevention".  The object
t is to detect the virus as early as possible.  You can't stop
that first infection (primary infection) from someone elses
system, but you may be able to stop it from infecting a
second file, or from actually doing damage to your system.

We're relagate d to fighting the symptons rather than the fi
viruses themselves.

Loren
=========================================================================
Date:         Thu, 28 Jul 88 16:49:06 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "David M. Chess 862-2245" <CHESS@YKTVMV>
Subject:      How many viruses are there?

Agreed, I didn't mean to be trying to pin you down to a specific
number.   I was just surprised to hear a number as high as 70;
I guess a lot more has been going on than anyone has mentioned
here or in similar places.   I'll be eagerly awaiting your posting
of your list!

I think the point about people using lots of different
anti-viral programs is a very good one; this is one field where
you don't want your own program to be the One Everyone Uses,
because if it is, the virus-writers will target it, take it
apart, and design circumventions.   Safety in Numbers!

DC
=========================================================================
Date:         Thu, 28 Jul 88 16:48:04 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Joe McMahon <XRJDM@SCFVM>
Subject:      Re: Questions about Brain
In-Reply-To:  Message of Thu, 28 Jul 88 14:14:37 EDT from <LKK0@LEHIGH>

>I'd like to know who all was hit the worst by the Christas
>Tree Exec.
IBM's VNET got it the worst. Most of the users there had literally hundreds
of ID's with which they had corresponded, with the result that thousands of
copies of the exec got out. They had to disconnect from BITNet for nearly
2 weeks (as I recall).

>How far did the Aldus virus get?
Not very. Remember, it's a self-limiting virus which burns itself out after
a one-time shot. It got into the warehouses, but there's little evidence it
actually hit the streets. Richard Brandnow's contention that he did it to
prove how much piracy was going on is an unmentionable substance found in
pastures. His claim on CompuServe was that he did because he wanted to. (Too
bad I can't type this in brimstone-spewing letters).

>Can anyone tell me about the NASA virus other than what was in
>the papers?  (NASA claims they didn't have a virus!)
Some people here may have had the Scores virus. I'm watching it here at
Goddard; we've got Vaccine to everyone we could find, along with KillScores
and Interferon.

--- Joe M.
=========================================================================
Date:         Thu, 28 Jul 88 16:38:48 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Joe McMahon <XRJDM@SCFVM>
In-Reply-To:  Message of Thu, 28 Jul 88 13:58:05 EDT from <LKK0@LEHIGH>

>                        ...For the Mac, I've seen aa version
>of the CHRISTA virus (yes, simple damn thing copies itself
>around your little Mac, its not written in Rex of course),
More information about this, please. I'm building a document about Mac
viruses. Resources, symptoms, etc. I can't use rumours.

>...the Phantom, the NASA virus, the Aldus virus, and the VULT
>virus...
The NASA virus and the VULT virus should be the same one, known as "Scores".
Is the Phantom a new one I haven't heard of? Symptoms please. What
resources are involved?

I would appreciate your pointing me to anyone who can prove that
either the Phantom or CHRISTMA virus exists. The CHRISTA sounds
like it is a nuisance bacterium rather than a viral infection. I
need technical data -- resource names/numbers, modifications made
by the viruses, etc.

>... the top of may head is a Mac virus which prints a picture
>of a nude female on the screen while it copies itself to any
>other disks in your system...
As I recall, this program shows the picture and erases your hard disk;
it doesn't propagate itself as a virus. Perhaps you mean a bacterium?

--- Joe M.
=========================================================================
Date:         Thu, 28 Jul 88 15:28:00 MDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         [e-mail]


        A relatively effective software strategy for an anti-viral program
        is to use the timer interrupt. It is done by installing a TSR
        which implements two functions:

        1- When loaded, it intercepts the timer interrupt vector. It
           then times its own execution and stores this duration with
           a checksum. This prevents its interrupt from being preempted
           by using timing dependencies.
        2- At 18 times per second, it compares interrupt vectors for
           modifications, these are flagged and, if restricted, they are
           disabled.

        The resolution is somewhat coarse considering the number of
        machine instructions that can execute between intervals, but it
        can effectively arrest the destruction of data.

        Kent Cearley
        Management Systems
        University of Colorado


=========================================================================
Date:         Thu, 28 Jul 88 16:55:12 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         SHERK@UMDD
Subject:      Questions about Brain
In-Reply-To:  Message received on Thu, 28 Jul 88  15:10:07 EDT

Here at the University of Maryland the (c) Brain virus was first noticed
about year and a half ago. We have several floopy based labs on campus
that are run by the business school. Data security at these labs was
not the best and eventually all the boot disks were infected. The version
of Brain we had was totally benign but a big stink was raised when the
Brain virus infected some floopies that had bad physical media. Every one
said that the Brain had mutated into a malignant virus!
Today, infections by the Brain virus are very rare on campus. We stamped
out the virus with a simple three part attack.

1. I down loaded the NOBRAIN.C program from VIRUS-L. With a fair amount
of hacking I made it work with the version of Brain we had. I distributed
the program to the Lab managers on campus, and for a while they put a
command to run the program in AUTOEXEC.BAT.

2. We had an campain to educate users on the importance of write protect
tabs.
3. And finally we stoped buying cheap disks.

I suspect that in September we will see it again, as students inadvertently
bring it back to school. With these simple precautions we should be ready
for it.

Although I have heard many rumors, I have yet to see any virus on the
University of Maryland campus that did any damage.

Erik Sherk
=========================================================================
Date:         Thu, 28 Jul 88 15:53:01 mdt
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
Comments:     Warning -- original Sender: tag was
From:         Bill Kinnersley <[e-mail]>
Subject:      Re: Trapping Direct Disk Write Calls

[In "Re: Trapping Direct Disk Write Calls", Len Levine said:]
>
> Very interesting about command.com.  That file, as released in
> msdos level 3.3 contains a 4000 byte block of zeros at its end, which
> makes it VERY easy to add code.
>
> I cannot fathom why they put that area into the process.
>
Perhaps they pad their software with zeroes to avoid possible shipping
damage.  :-)

=========================================================================
Date:         Thu, 28 Jul 88 15:12:00 PDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         [e-mail]
Subject:      RE: Re: Trapping Direct Disk Write Calls

test posting, please ignore.
=========================================================================
Date:         Thu, 28 Jul 88 23:25:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Jim Shaffer, Jr." <SHAFFERJ@BKNLVMS>
Subject:      RE: Questions about Brain

>[...]
>
>Does anyone have a copy of the Apple version of Core Wars?
>

A Macintosh version of Core Wars can be obtained from [e-mail]
by sending the command (in the first line of a MAIL message)
$MAC GET DEMO-COREWARS.HQX

This will get you the BinHex-ed version of the program, along with the
documentation.  You'll need BinHex and PackIt (or UnPackIt) (or is it StuffIt;
I don't remember, sorry) to recreate the application.  If you don't have
them, ask around.  Someone local should have them.

>
>[...]
>
>I'd like to know who all was hit the worst by the Christas
>Tree Exec.

The worst case, based on reports in RISKS TO THE PUBLIC IN THE USE OF COMPUTERS
AND OTHER AUTOMATED SYSTEMS (a.k.a. RISKS Digest) would have to be IBM's
internal network, called VNET.  It slowed it down to such an extent that
most of it had to be shut down until the program could be removed from the
mail queues.

>[...]

>Can anyone tell me about the NASA virus other than what was in
>the papers?  (NASA claims they didn't have a virus!)

This is a new one to me, I think.
SPAN/HEPNet had one H*ll of a case of crackers, though!  They almost made
VMS Security an oxymoron.

>[...]
>Loren

_______________________________________________________________________________
|  James M. Shaffer, Jr.   | Bitnet: shafferj@bknlvms     CIS: 72750,2335     |
|  P.O. Box C-2658         | Internet: [e-mail]|
|  Bucknell University     | UUCP: ...!psuvax1!bknlvms.bitnet!shafferj        |
|  Lewisburg, PA USA 17837 | CSNet: [e-mail]      |
-------------------------------------------------------------------------------
| "He's old enough to know what's right and young enough not to choose it;    |
|  He's noble enough to win the world but fool enough to lose it."            |
|                                   -- Rush, "New World Man", on _Signals_    |
-------------------------------------------------------------------------------
Disclaimer:  I'm not the list owner!  (See the last NetMonth.)       :-)
=========================================================================
Date:         Fri, 29 Jul 88 00:41:46 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Loren K Keim   -- Lehigh University <LKK0@LEHIGH>

Joe:

Regarding different viruses.  When I said the VULT virus, I
was referring to the Scores virus but scouldn't think of
the name at the time.  I also am not sure if the NASSA virus
was Scores or not.  A phone call to them got me a nasty
message that NASA didn't have a virus just a little hardware
problem that got out of hand.  (Isn't that what the spce
shuttle was?)

The Christma Virus, as well as the nude women viruses I've
seen on the Mac are just programs which print a picuture,
look for a hard disk and copy themselves to it.  I believe
the ones with the nude women pictures were actually just
programs someone wrote and someone else added the copy part.
The problem with these viruses is taht you can't really stop
a program from copying itself from disk to disk.  I hadn't
seen one which destoryed the FAT table, just ones that copy
themselves.  I hesitate to even dcall them viruses because
they really dont' do anything other than propogate, but htat
IS the definition of the virus.

The Phantom attaches itself to executables.  All the phantom
does is print a little message about the Phatntom being
some force of good and how no eveil will escape it and then
it deletes its own code.  I think its probably like the Aldus
virus, but I'm not a Mac person.

If you have a copy of a nude woman program that kills your
hard disk, I wonder if it is the same nude woman program?
]I wonder why the writer did not put them dtogether?

You refer to bacteriaum quite often.  Do you mean Trojans?
Unfortunately, when I refer to worm, its a speacial case of
a computer virus.

Loren Keim
=========================================================================
Date:         Fri, 29 Jul 88 02:51:52 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Amanda B Rosen <[e-mail]>
Subject:      Re: Mac viruses

Loren Keim writes:

>                           For the Mac, I've seen aa version
>of the CHRISTA virus (yes, simple damn thing copies itself
>around your little Mac, its not written in Rex of course),
>the Phantom, the NASA virus, the Aldus virus, and the VULT
>virus.  [and also a "playboy" type virus]

By the VULT virus, I presume you mean the one more commonly known as
"SCORES."  But this is the first I've heard mention of the "Phantom"
virus. I heard rumors of a NASA virus and a "Playboy" virus, but
nothing substantial. Could you please describe these, _in detail_?

I believe the Aldus virus you mention is the MacMag "Peace" virus.
Is there a different CHRISTMA-type virus out there? What does it do?

We have heard of one other virus- the "sneak."  We have no information
about it. Do you know if it really exists?

/a
=========================================================================
Date:         Thu, 28 Jul 88 22:15:00 -0500
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
Comments:     converted from NETDATA format at UOFMCC
From:         Steve Morrison <[e-mail]>
Subject:      request for opinions on future...
In-Reply-To:  <270*[e-mail]>

The scenario could be a mad-hacker, plugging away at a keyboard in
the back of a dimly lit office, creating a virus like no virus ever
seen before.  Viruses are going to be like methods of cheating at
cards or on your spouse.  The analogy would be having mice evolve
into a bigger species to defeat mouse traps - unless the traps are
built bigger, the mice will win.

Thoughts from someone who was out in sun today....
Devo_Stevo aka Stephen D. Morrison
[e-mail]
=========================================================================
Date:         Fri, 29 Jul 88 06:21:03 mdt
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
Comments:     Warning -- original Sender: tag was
From:         Bill Kinnersley <[e-mail]>
Subject:      Bacteria

[In "", Loren K Keim   -- Lehigh University said:]
>
> The Christma Virus, as well as the nude women viruses I've...
>
> themselves.  I hesitate to even dcall them viruses because
> they really dont' do anything other than propogate, but htat
> IS the definition of the virus.
>
> You refer to bacteriaum quite often.  Do you mean Trojans?
> Unfortunately, when I refer to worm, its a speacial case of
> a computer virus.
>
Both viruses and bacteria are self-propagating.  The distinction is that
a virus usually does so in a restricted fashion, to avoid detection while
it does its dirty work.  A bacterium's goal in life is to propagate
rapidly without bound and thereby usurp the resources of the host system.
The CHRISTMA Virus, I believe, was really a bacterium.

=========================================================================
Date:         Fri, 29 Jul 88 09:38:36 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Kenneth R. van Wyk" <LUKEN@LEHIIBM1>
Subject:      (revised) Monthly greeting from Ken


[ Last modified 29-July-88 - Ken van Wyk ]

Welcome!  This is the monthly introduction posting for VIRUS-L,
primarily for the benefit of any newcomers.  Apologies to all
subscribers who've already read this in the past (you'll only have to
see it once a month and you can, if you're quick, press the purge
key...:-).


What is VIRUS-L?

It is an electronic mail discussion forum for sharing information
about computer viruses.  Discussions should include (but not
necessarily be limited to): current events (virus sightings), virus
prevention (practical and theoretical), and virus questions/answers.
The list is non-moderated and non-digested.  That means that any
message coming in goes out immediately.  Weekly logs of submissions
are kept for those people who prefer digest format lists (see below
for details on how to get them).


What isn't VIRUS-L?

A place to spread hype about computer viruses; we already have the
Press for that.  :-)  A place to sell things, to panhandle, or to
flame other subscribers.  If anyone *REALLY* feels the need to flame
someone else for something that they may have said, then the flame
should be sent directly to that person and/or to the list moderator
(that'd be me, <[e-mail]>).


How do I get on the mailing list?

Well, if you're reading this, chances are *real good* that you're
already on the list.  However, perhaps this document was given to you
by a friend or colleague...  So, to get onto the VIRUS-L mailing list,
send a mail message to <[e-mail]>.  In the body of the
message, say nothing more than SUB VIRUS-L your name.  LISTSERV is a
program which automates mailing lists such as VIRUS-L.  As long as
you're either on BITNET, or any network accessible to BITNET via
gateway, this should work.  Within a short time, you will be placed on
the mailing list, and you will get confirmation via e-mail.


How do I get OFF of the list?

If, in the unlikely event, you should happen to want to be removed from
the VIRUS-L discussion list, just send mail to
<[e-mail]> saying SIGNOFF VIRUS-L.  People, such as
students, whose accounts are going to be close (like over the
summer...) - PLEASE signoff of the list before you leave.  Also, be
sure to send your signoff request to the LISTSERV and not to the list
itself.  Note that the appropriate node name is LEHIIBM1, not LEHIGH;
we have a node called LEHIGH, but they are *NOT* one and the same.


How do I send a message to the list?

Just send electronic mail to <[e-mail]> and it will
automatically be redistributed to everyone on the mailing list.  By
default, you will NOT receive a copy of your own letters.  If you wish
to, send mail to <[e-mail]> saying SET VIRUS-L REPRO


I can't submit anything to the list - what's wrong?

There have been a few cases where people found that they were unable
to send anything in to VIRUS-L even though they were registered
subscribers (only subscribers can participate).  Let me try to explain.
The LISTSERV program differentiates lowercase from UPPERCASE.  So,
if you've subscribed to the list as (for example) [e-mail]
and your mail is actually coming through as [e-mail], then
the LISTSERV will think that you're not subscribed to the list.
BITNET usernames and node names are automatically uppercased by
the LISTSERV, but other network addresses are not.  If your site
(or you) should happen to make a change to, say, the system mailer
such that it changes the case of your mail, there will be problems.
If you're having problems submitting (you'll know this because
the LISTSERV will say "Not authorized to send to VIRUS-L..."), try
unsubscribing and re-subscribing.  If that doesn't work, send me
mail ([e-mail]), and I'll try to fix things up.


What does VIRUS-L have to offer?

All submissions to VIRUS-L are stored in weekly log files which can be
downloaded by any user on (or off) the mailing list; readers who prefer
digest format lists should read only the weekly logs.  There is also a
small archive of some of the public anti-virus programs which are
currently available.  This archive, too, can be accessed by any user.
All of this is handled automatically by the LISTSERV here at Lehigh
University (<[e-mail]>).


How do I get files from the LISTSERV?

Well, you'll first want to know what files are available on the
LISTSERV.  To do this, send mail to <[e-mail]> saying
INDEX VIRUS-L.  Note that filenames/extensions are separated by a
space, and not by a period.  Once you've decided which file(s) you
want, send mail to <[e-mail]> saying GET filename
filetype.  For example, GET VIRUS-L LOG8804 would get the file called
VIRUS-L LOG8804 (which happens to be the monthly log of all messages
sent to VIRUS-L during April, 1988).  Note that, starting June 6, 1988,
the logs are weekly.  The new file format is VIRUS-L LOGyymmx where
yy is the year (88, 89, etc.), mm is the month, and x is the week
(A, B, etc.).  Readers who prefer digest format lists should read
the weekly logs and sign off of the list itself.  Subsequent submissions
to the list should be sent to me for forwarding.

Also available is a LISTSERV at SCFVM which contains more anti-virus
software.  This LISTSERV can be accessed in the same manner as outlined
above, with the exceptions that the address is <[e-mail]>
and that the commands to use are INDEX PUBLIC and GET filename filetype
PUBLIC.


What is uuencode/uudecode, and why do I need them?

Uuencode and uudecode are two programs which convert binary files into
text (ASCII) files and back again.  This is so binary files can be
easily transferred via electronic mail.  Many of the files on this
LISTSERV are binary files which are stored in uuencoded format (the
file types will be UUE).  Both uuencode and uudecode are available from
the LISTSERV.  Uudecode is available in BASIC and in Turbo Pascal here.
Uuencode is available in Turbo Pascal.  Also, there is a very good
binary-only uuencode/uudecode package on the LISTSERV which is stored
in uuencoded format.


Why have posting guidelines?

To keep the discussions on-track with what the list is intended to be;
a vehicle for virus discussions.  This will keep the network traffic
to a minimum and, hopefully, the quality of the content of the mail to
a maximum.  No one wants to read personal flames ad nausium, or
discussions about the pros and cons of digest-format mailing lists,
etc.



What are the guidelines?

     As already stated, there will be no flames on the list.  Anyone
     sending flames to the entire list must do so knowing that he/she
     will be removed from the list immediately.

     Same goes for any commercial plugs or panhandling.

     Submissions should be directly or indirectly related to the
     subject of computer viruses.

     Responses to queries should be sent to the author of the query,
     not to the entire list.  The author should then send a summary
     of his/her responses to the list at a later date.

     "Automatic answering machine" programs (the ones which reply
     to e-mail for you when you're gone) should be set to *NOT*
     reply to VIRUS-L.  Such responses sent to the entire list
     are very rude and will be treated as such.

     When sending in a submission, try to see whether or not someone
     else may have just said the same thing.  This is particularly
     important when responding to someone else's posting (which should
     be sent to that person *anyway*).  It's very easy to get multiple
     messages saying the exact same thing.  No one wants this to
     happen.

Thank-you for your time and for your adherance to these guidelines.
Comments and suggestions, as always, are invited.  Please address them
to me, <[e-mail]> or <[e-mail]>.



Ken van Wyk

Kenneth R. van Wyk                    From the Devil's Dictionary:
User Services Senior Consultant          Barometer - an ingenious device
Lehigh University Computing Center         designed to inform the user what
Internet: <[e-mail]>       the weather is.
BITNET:   <LUKEN@LEHIIBM1>
=========================================================================
Date:         Fri, 29 Jul 88 10:05:15 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Joe McMahon <XRJDM@SCFVM>
In-Reply-To:  Message of Fri, 29 Jul 88 00:41:46 EDT from <LKK0@LEHIGH>

A "bacterium" is a program which, in addition to doing something
innocuous, creates copies of itself and spreads them. If you are on a
network, it will try to spread itself across the net. Otherwise, it
puts itself on all of the disks it can find. It does not sit around
and try to reproduce itself by hooking into the system; it only
reproduces when executed.  The CHRISTMA EXEC is a bacterium.

--- Joe M.
=========================================================================
Date:         Fri, 29 Jul 88 10:54:00 EST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         GILL@QUCDNAST
Subject:      New FluShot+  ?

     I just got a copy of FluShot+ V1.4 in the mail today from Ross
Greenberg.  The version date is June 21/88.  Is this the new version
that was hinted at on the net about 2 months ago?  Has anyone tried
using it yet?  Are there copies on the LISTSERV?  Do you want a copy on
LISTSERV?  I can send it if requested (and told where to send it).

     (I haven't done any testing yet, as my hard disk has decided to die.
The doctors tell me it must be replaced.  Has anyone ever heard of a hard
disk life span of 2.5 years???)

                                          -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Arnold Gill                              | If you don't complain to those who  |
Queen's University at Kingston           | implemented the problem, you have   |
gill @ qucdnast.bitnet                   | no right to complain at all !       |
                                          -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
=========================================================================
Date:         Fri, 29 Jul 88 19:03:02 +0300
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "Y. Radai" <RADAI1@HBUNOS>
Subject:      Virus lists

  Several people have asked for lists of known viruses.  Back in May I was told
that Steve Gibson of Infoworld had requested examples of viruses and had re-
ceived about 40 of them.  I don't receive Infoworld, but if this information is
correct, it seems to me that Steve should be willing to provide names and/or
descriptions of them if someone were to contact him.  (Maybe he's already
published them in Infoworld.)

                                           Y. Radai
                                           Hebrew Univ. of Jerusalem
=========================================================================
Date:         Thu, 28 Jul 88 19:56:13 CST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         James Ford <JFORD1@UA1VM>
In-Reply-To:  Message of Thu, 28 Jul 88 15:59:51 EDT from <LKK0@LEHIGH>

     Here's one Alabama person on the list.  How may I help you?

                         James Ford
=========================================================================
Date:         Fri, 29 Jul 88 11:19:55 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
Comments:     Resent-From: Marilyn Everingham <11600ME@MSU>
Comments:     Originally-From: Marilyn Everingham <11600ME@MSU>
From:         Marilyn Everingham <11600ME@MSU>

Let me introduce myself first... I'm the computing newsletter editor at
Michigan State University and I joined this list to learn more about virii
(which I certainly have).  Now I am in the process of thinking about dis-
seminating some of the information and have a question.

I ran across some descriptions of virus types in an InfoWorld editorial and
am wondering if they are generally accepted descriptions or something the
writer invented.  If anyone (and I'm sure many will) has opinions/facts/
ideas, please let me know.

The virus descriptions are:
GPIV -- General Purpose Infector Virus -- operates by tacking itself onto the
front or back of any existing application program, generally specific to COM or
EXE files.

SPIV -- Special Purpose Infector Virus -- designed to inhavit only one version
of one particular application program which makes it harder to detect.

VCGPIV -- Very Clever General Purpose Infector Virus -- combines the features
and capabilities of the GPIV with those of the SPIV and is able to find non-
code-bearing regions within the bodies of other application programs for which
it was not specifically designed and infect those programs; one of the
hardest to spot or control; worst variations of this virus don't begin
causing trouble until sometime after every last cadidate host application
program in the system has been infected.

CSIV -- Central System Infecting Virus -- doesn't fool around with infecting
individual application programs but attacks and alters the core of the
operating system; usually carried by a Trojan horse.

Thanks in advance for help and ideas.

/me
=========================================================================
Date:         Fri, 29 Jul 88 15:34:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "David M. Chess 862-2245" <CHESS@YKTVMV>
Subject:      "Virus" or "Bacterium"

We had a big brouhaha around here about what names to use for what.
For practical purposes, it seems useful to distinguish between
programs that just spread themselves at the >file< level (for
instance, a FUN.EXE that copies itself, as FUN.EXE, to all the
disks it can find), and code-fragments that insert themselves
>into< already-existing executable files (as, for instance, the
Jerusalem virus does).  The biological analogies would suggest
calling the latter things "viruses", and the former things
"bacteria" (since bacteria reproduce on their own, while
viruses insert themselves into already-existing cells).

In general, bacteria are pretty easy to check for and kill
("inspect your disks for FUN.EXE, and erase it if found, without
executing it"), while viruses are much harder (it doesn't
make any sense to ask for a list of known virus-infected
programs, for instance, since *any* executable file can come
to contain a Jerusalem-type virus).

It can be very hard to draw a firm line between the two, though,
and it's not clear where the "(c) Brain" thing (for instance)
fits into this distinction...

DC
=========================================================================
Date:         Fri, 29 Jul 88 16:39:17 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Loren K Keim   -- Lehigh University <LKK0@LEHIGH>

I received a number of confusing letters over the night.
Apparently, some of you got my last letter and some didn't.
I received an error that it didn't go out, but yet I
received several replies on it.

To recap quickly, what I said was that the CHRISTMA program
for the Mac was simply an executable file.  When it is run,
it copies itself to your hard disk if it can find one, or
back to a floppy if its run on a hard disk.  Its not a
very exciting program.

The Phantom virus was sent to me from Maine, and I believe
it is a re-vamped version of the Aldus virus, although I
haven't got a copy of the Aldus virus.  The Phantom simply
will come up on your screen and say some message about
justice.  I will look back at my notes when I get home
tonight and write out the exact message.

Just to let you know, I seem to have received a threat-type
letter today.  It simply said that the PERFECT virus is
on its way.  It was a simple piece of laser printed paper
left on my car window.

I'm not sure if it was a joke or a threat.

Loren
=========================================================================
Date:         Fri, 29 Jul 88 16:38:49 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         "David M. Chess" <CHESS@YKTVMV>
Subject:      GPIV, SPIV, etc.

I'm pretty sure those were made up by the Tech Talk feller especially
for that column.   I've never seen them anywhere else and, while
they helped organize the column nicely, they don't really seem
generally useful: a one-sentence description ("this virus infects
only FINOGACALC.EXE") will be much more generally understandable
than, say, "this is a SPIV".

DC
=========================================================================
Date:         Fri, 29 Jul 88 16:59:35 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Loren K Keim   -- Lehigh University <LKK0@LEHIGH>

First, I am having trouble sending mail to JFord and DHunt
at their respective nodes.   If either of you have alternate
addresses, please send them to me, otherwise, I'll have to
find a way around the points that are stopping me.

Actually, I'm looking for Vin McL's address here as well,
my mail to him doesn't seem to get through.

Actually, since we are all spending so much time wishing
to view each other's viruses and anti-viral programs,
we should actually try to get this rather large group
together at some point.

If anyone would be interested in such a conference, please
tell me (LKK0@LEHIIBM1) and I'll be happy to arrange one.

Loren Keim
=========================================================================
Date:         Fri, 29 Jul 88 17:29:00 EDT
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         Woody <WWEAVER@DREW>
Subject:      interesting statistic


the August 1 issue of Business Week states
"  No one knows how many viruses have been planted.  But John D. McAfee, a
virus expert at InterPath Corp., a security consulting firm in Santa Clara,
Calif., says there have already been 250,000 outbreaks.  He estimates that
40 of the nation's largest industrial companies have been infected..."
=========================================================================
Date:         Sat, 30 Jul 88 00:51:49 CST
Reply-To:     Virus Discussion List <VIRUS-L@LEHIIBM1>
Sender:       Virus Discussion List <VIRUS-L@LEHIIBM1>
From:         James Ford <JFORD1@UA1VM>
Subject:      "Bug" in mailer?

     Well folks, I'm not sure who to send this to, but since it was to
Loren (LKK0 at LEHIIBM1) this list seems to be as good as any.  Now, I
have absolutely NO knowledge about REXX, but when it says "recipient OK",
it should get there(?).

     I hate to sound like I'm turning this into MAILER-L or REXX-L,
but............    :-)

                           James Ford
                           JFORD1 (notice the "1") @UA1VM

P.S.  The "purge" key should come in handy to some folks.......



-------------------  message follows ------------------------------------
>========================================================================
>Received: from LEHIIBM1.BITNET by UA1VM.BITNET (Mailer X1.25) with BSMTPid
>4492; Fri, 29 Jul 88 16:05:15 CST
>Received: from LEHIIBM1.BITNET by LEHIIBM1.BITNET (Mailer X1.25) with BSMTP id
>1358; Fri, 29 Jul 88 16:48:58 EDT
>Date: Fri, 29 Jul 88 16:48:57 EDT"F
>From: Network Mailer <[e-mail]>
>To: [e-mail]
>Subject: mail delivery error

>Batch SMTP transaction log follows:

>220 LEHIIBM1.BITNET Columbia MAILER X1.25 BSMTP service ready.
>050 HELO UA1VM.BITNET
>250 LEHIIBM1.BITNET Hello UA1VM.BITNET
>050 TICK 4418
>250 4418 ... that's the ticket.
>050 MAIL FROM:<[e-mail]>
>250 <[e-mail]>... sender OK.
>050 RCPT TO:<lkk0@lehiibm1>
>250 <lkk0@lehiibm1>... recipient OK.
>050 DATA
>354 Start mail input.  End with <crlf>.<crlf>
>554-Mail not delivered to some or all recipients:
>554 No such local user: LKK0
>050 QUIT
>221 LEHIIBM1.BITNET Columbia MAILER BSMTP service done.

>Original message follows: